Throwing this error for response success but not able to redirect the page how to login and redirect,how to fix this error :
error.errorCode: invalid_request, error.description: The
'redirect_uri' parameter must be an absolute URI that is whitelisted
in the client app settings.
there couple of places you should check.
1) okta developer dashboard. when we create an application there, the default value of Login redirect URIs is "http://localhost:8080/authorization-code/callback". if your web site's call back url is different from it, you have to update it to here. for example, my call back url is "http://localhost:8001/Home/Authenticate".
2) if you have a config value in your web site. make sure the config value is updated to the same URL, my case is in ASP.NET web.config => appSettings, update the value of "okta:RedirectUri" to "http://localhost:8001/Home/Authenticate"
3) if you are using okta sign-in widget and you want to redirect to your web page, you need to ensure the JavaScript, when you create OktaSignIn object, did you specify redirectUri? if so, make sure you have the right Url there. more details about the widget click here
var signIn = new OktaSignIn({
baseUrl: 'https://dev-*******.okta.com',
clientId: '${clientId}',
redirectUri: '${redirectUri configured in OIDC app}',
authParams: {
issuer: 'default',
responseType: ['id_token','token'],
display: 'page'
}
});
This one place I found useful for the above redirect_uri error:
https://support.okta.com/help/s/article/The-redirect-uri-parameter-must-be-an-absolute-URI?language=en_US
Although it is for login URI, but I assume you are passing the URI at right place, just that it may be relative. Make sure that URI is absolute.
Related
I am using MSAL.js for a javascript based single page application.
We have configure Azure Ad for implicit authentication.
The redirection url also has been configured to a page.
However we have a requirement where we get a daily email report. This email has links to the application page but with query parameters that allows to filter the report for that day.
Now if we access the app via the landing page, we are able to login fine. But with the query params it gives the exception "The reply URL specified in the request does not match the reply URLs..".
I am using the endpoint V2 on Azure AD , hence not able to put * in the reply url. I guess this is an existing problem. But is there some way to overcome the issue of logging in & redirection with parameters?
Thanks,
Ash
The approach we have taken in general with our apps is to specify a specific URL to MSAL as the redirect URL, and redirect to the "local URL" from there.
So when you send a user to authenticate, you store the current path somewhere like in local/session storage.
Then when the user hits that callback page, you can load up the path from storage and redirect the user there.
This way you can avoid wildcard usage, and still get the user where they wanted to go.
You can tell MSAL not to redirect to the current URL and specify the redirect URL like this:
const app = new UserAgentApplication({
auth: {
// Other settings left out for brevity
navigateToLoginRequestUrl: false,
redirectUri: window.location.origin + '/auth-callback'
}
});
In Case of SPA with login redirect at landing on page with querystring parameter you can use the following configuration to preserve querystring parameter after login (MSAL 2.0)
export const msalConfig = {
auth: {
clientId: "YOUR_CLIENT_ID",
authority: "YOUR_AUTHORITY_URL",
redirectUri: window.location.origin
}
Not a duplicate of Facebook login message: "URL Blocked: This redirect failed because the redirect URI is not whitelisted in the app’s Client OAuth Settings."
This issue is about CakePHP sending the wrong URL. It is fully understood why Facebook doesn't like the URL, not clear how to fix it in CakePHP
Trying to use this HybridAuth plugin for Cakephp, everything seems to be working except the redirect URL has http, which facebook does not like. I need to make it https. I cannot figure out how to manipulate this value.
https://www.facebook.com/v2.12/dialog/oauth?auth_type=rerequest...redirect_uri=http%3A%2F%2Fwww.example.com%2Fhybrid-auth%2Fendpoint%3Fhauth_done%3DFacebook&scope=email%2Cpublic_profile
Which gives me this error, which makes sense:
URL Blocked: This redirect failed because the redirect URI
is not whitelisted in the app’s Client OAuth Settings. Make
sure Client and Web OAuth Login are on and add all your app
domains as Valid OAuth Redirect URIs.
I've been trying to fix this for about two hours. I've tried setting
'hauth_return_to' => [
'controller' => 'Lookings',
'action' => 'find',
'prefix' => false,
'plugin' => false,
'_ssl' => true
]
in the AppController authenticate settings for HybridAuth, which doesn't seem to do anything. Also tried a lot of random things around the internet that just seemed to break more things. I'm a bit lost now.
New update
I have tracked this URL's origin as far as the loginBegin method in hybridauth/Hybrid/Providers/Facebook.php, and it's in $this->params['login_done']; though I'm uncertain now where this is being set.
Old update
Updating the Appcontroller authenticate settings still doesn't seem to affect this particular URL no matter what I do. I believe this setting is related to the "URL Login done" redirect URL, and my issue is with the "URL Start login" URL, though I'm not entirely certain.
Add the 'base_url' property to the HybridAuth object in /config/hybridauth.php to manually set the base URL.
Additionally, it appears that base_url is create using $_SERVER['HTTPS'], which is apparently not set to true in my current environment. This can be found in the login method of the Hybrid_Provider_Adapter class.
Addressing either of those issues should fix the problem.
We have discovered that our users very often for the first time visits our web application by browsing the direct URL of the OIDC client (https://oidcclienturl.com/), The ASP.NET Core OIDC authentication middleware kicks in and the user gets redirected back to Identityserver 4 login page.
Everything works fine but then they decide to add the (temporary? state, nonce, cookies...) authorization URL as a bookmark in their browser before entering their credentials and continuing back to the web application.
This causes an issue when the user later uses the bookmark in a new session. The login seem to actually work after entering valid user credentials even if the user uses an old authorization URL, but when the user gets redirected back to the web application they end up on a blank page (https://oidcclienturl.com/signin-oidc).
After the blank page have been loaded the user is able to browse the direct URL (https://oidcclienturl.com/) sucessfully and appear as an authentcated user in the web application.
Any ideas whats causing the blank page?
That blank page shouldnt exist, if I understand it correctly its the default callback path of the oidc authentication middleware in ASP.NET Core.
Unfortunately, the real-world problem of users bookmarking the login page isn't handled cleanly by OIDC, which requires the client app to initiate the login flow.
I've addressed this by adding a RegistrationClientId column to my user data table, which is the Identity Server ClientId corresponding to the client app that called IDS when the user account was created. In the client app configuration, we use the custom Properties dictionary to add a URI fragment:
new Client
{
ClientId = "some_client",
ClientName = "Some Client",
ClientUri = "https://localhost:5000",
Properties = new Dictionary<string, string>
{
{ "StartLoginFragment", "/Auth/StartLogin" }
}
// other config omitted
};
When a user logs in, an empty return URL indicates IDS wasn't called by a client app, so we use RegistrationClientId to query IClientStore, then we combine the ClientUri and StartLoginFragment URIs and use the resulting URI to redirect the user back to the client application.
Over in the client application, that endpoint kicks off the OIDC sign-in flow, and since the user is already signed-in on IDS, it comes right back to the correct location in the client app. The controller action looks like this:
[HttpGet]
public async Task StartLogin()
{
await acctsvc.SignOutAsync();
await HttpContext.ChallengeAsync("oidc",
new AuthenticationProperties()
{
RedirectUri = "/"
});
}
The call to SignOutAsync just ensures any client-app signin cookies are cleaned up. It's in our custom account service, but it just runs HttpContext.SignOutAsync on the usual "Cookies" and "oidc" schemes. Normally that would also result in a signout call to IDS, but the redirection by the subsequent ChallengeAsync replaces the pending signout call.
The downside is that the action is an HTTP GET meaning pretty much anyone could theoretically trigger this action. At most it would be an annoyance.
In the special case where your IDS is only handling auth for a single client, you can skip a lot of that -- if they land on the page with no return URL, just send them to your client app start-login endpoint straightaway, before they login.
I have registered an angular app with Azure AD for authentication. After auth, Azure redirects back to my app as designated by the "Reply Url" in the Azure config.
Reply Url = http://myapp.com/#/?
The app expects url parameter fragments (such as auth code, token, state, etc) appended to the redirect url, which are checked if user auth succeeded.
Redirect Url = http://myapp.com/#/?code=<some code>&id_token=<id token>&...
This was working before, but as of yesterday the redirect url now looks like this
Redirect Url = http://myapp.com/#code=<some code>&id_token=<id token>&...
No changes were made to the app config in azure management portal.
This new format is breaking angular routing in the app, and the auth parameters are not being captured/parsed. Everything after the "#" in the reply url seems to be ignored.
Any idea as to what causes the redirect url not to use the complete reply url configured in Azure AD?
As I know, Reply Url configured on Azure AD is just to validate the location.origin of the redirected url.
This redirected url can be configured by setting redirectUri option in the adalAuthenticationServiceProvider.init method (as you're making Angular app).
Back to your question, I have same redirect url format #id_token=... without ? character. But all good for me because I can access all necessary values by accessing adalAuthenticationService.userInfo object.
Check out here for more detailed info.
Hope it helps in your case.
What I did was to use HTML5 mode on the Angular side.
You can see how I configured ADAL and routing:
$locationProvider.html5Mode(true).hashPrefix("!");
var endpoints = {
"/api": "https://app-id-uri"
};
adalAuthenticationServiceProvider.init(
{
clientId: "12345678-1234-1234-1234-123456789012",
endpoints: endpoints
},
$httpProvider
);
On server-side it was then important to return the index page no matter what route was hit, since routing is done client-side. Now AAD returns the code in the fragment as usual and all routing works as well.
I have an AngularJS app, and a WebApi2 with ASP.NET Identity 2.0.
I am trying to log user in using Facebook account.
I am using this answer to do it.
Getting auth providers is easy, I have problem with the next step.
It says, I should make GET request to my WebApi server, using the Url provided before.
So I make my call and get a HTTP 302 with Location header set to facebook's login page.
The browser doesn't redirect, however.
In Developer Tools I see that GET request to this address is made, but then in console there is
XMLHttpRequest cannot load [url here]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' therefore not allowed access.
I know this is related to CORS, but like it expects CORS enabled on Facebook's side?
From what I understand: after loggin to Facebook, it redirects me back to my WebApi method registering ExternalLogin, and than back to my AngularApp. Is that correct?
Here's code of my login function:
function facebookLogin() {
getExternalLogins().then(function (data) {
var providerData = null;
for (var i = 0; i < data.length; i++){
if(data[i].Name == 'Facebook'){
providerData = data[i];
break;
}
}
if(providerData != null) {
window.location.href = serverBaseUrl + providerData.Url;
}
},
function (error, status) {
});
}
Update:
I've managed to redirect to Facebook's login page, thanks to CBroe's comment.
The next problem is that after logging in, Facebook redirects me to my WebApi.
How can I redirect user back to Angular app? WebApi can be called from various places, not only from example.com but from example1.com or example2.com also.
Maybe it would be a better idea to perform this login client-side using Facebook API, and then notify the server about it?
But how to perform login on WebApi using FB authResponse?
Try the following steps, they solved the issue for me (for a different login provider):
Remove the built-in login page and controller, and the option to use
ASP.Net identity from the web application; see this article.
Add credentials in the $.ajax call (see below) of in $http:
xhrFields: {
withCredentials: true
},
Add to your web.config the following to enable CORS:
<add name="Access-Control-Allow-Origin" value="FACEBOOK_APP_URL" />
<add name="Access-Control-Allow-Credentials" value="true"/>