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
}
Related
I am currently using Microsoft adal angular for Azure active directory authentication and below if the configuration settings for the same.
MsAdalAngular6Module.forRoot({
tenant: 'xxxxxxxxxxxxxxxxxxx',
clientId: 'xxxxxxxxxxxxxxxxx',
redirectUri: window.location.origin,
endpoints: {
"xxxxxxxx": "xxxxxxxxxxxxxx",
},
navigateToLoginRequestUrl: true,
cacheLocation: 'localStorage',
loadFrameTimeout: 60000
}),
I have set reply URL as https://xxx.azurewebsites.net/ in Azure app registrations.
The above configuration works fine if I use https://xxx.azurewebsites.net/ and enter into the application. But when I use https://xxx.azurewebsites.net/dashboard and enter my credentials it is throwing the error mentioned in the subject and not allowing me to go in.
I know that the Azure has blocked wild card configurations in Active directory. Is there a way for me to configure the settings to successfully authenticate If I copy-paste any deep link from the application.
Any help would be really appreciated and thanks in advance.
When the redirect_uri in the authorization request mismatches the redirect url configured in Azure AD registrations, you will encounter this error.
So if you want to use https://xxx.azurewebsites.net/dashboard in your request, you should also add it as the redirect url of your Azure AD registrations.
Update:
Based on our discussion, you just need to specify the redirect URL in your code as the same url as what you have configured in your Azure AD app: https://xxx.azurewebsites.net to meet your requirement.
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.
I am trying to integrate my application with AAD authentication but the replyurls which i am configuring in the AAD application is
https://www.example1.com/abc/account/login.aspx
but when i am coming back after authentication i am getting redirected to
https://www.example1.com/
Only and my request is coming as authenticated but i want user to redirect to full url which i have configured.
I have tried sending RedirectUri at the time of app configuration in startup class as same as https://www.example1.com/abc/account/login.aspx that time user is redirect to this url but that time request is not getting authenticated
any one knows how i will achieve this?
thank you in advance.
Reply URL is where the token would send to . It means that it is a endpoint
which signs in users for that provider. But after signing in, the user will be redirect to the Homepage(Sign-on) URL.
For your scenario, you can change the Home page (Sign-on)URL in both AAD Application and your APP config file to the URL which you want to use.
Please refer to this documentation for detailed instructions on how to set up these configurations. Like Wayne said, you need to make sure that the home page URL is matched to whatever site you want the users to be redirected to after login. Then make sure that the reply URL and the RedirectURI are matching.
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.