I have a custom policy in Azure AD B2C and am trying to implement a session timeout. If a user first logs in, then the timeout expires, then they attempt to log in again, they should be prompted for their user name and password again.
First I followed the instructions here to set token_lifetime_secs and id_token_lifetime_secs to 20 minutes (1200 seconds) in the TechnicalProfile for JwtIssuer in my TrustFrameworkBase.xml: https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-tokens-custom-policy
Then I uploaded my updated TrustFrameworkBase.xml.
Then I logged in from my app using my custom policy and waited 20 minutes. I tried to log in again, and was immediately authenticated and directed back to my app. I was not prompted for my user name and password again as I was expecting.
There are two previous questions on stackexchange that seem to be the same as this, but they share the same solution which no longer works (it was retired in May 2020), so I am looking for a new solution:
Azure AD B2C logout after session timeout
Missing Azure AD B2C b2c-extensions-app
It is because you adjusted the token lifetime and not session lifetime.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/session-behavior-custom-policy
Instead change the session lifetime as follows
<UserJourneyBehaviors>
<SingleSignOn Scope="Application" />
<SessionExpiryType>Absolute</SessionExpiryType>
<SessionExpiryInSeconds>86400</SessionExpiryInSeconds>
</UserJourneyBehaviors>
It is the cookie that is giving you SSO next time you hit the B2C page not the tokens.
Related
I have a React app that uses Azure B2C to authenticate users (PKCE flow).
There is a requirement to keep the session active as long as the user has some activity.
I cannot use "Rolling" for session timeout, because some of the requests are made by an independent job, which is not triggered by the user.
Here is my question - how can I control renewing the session? I would like to renew the session every time I am getting the access token.
Access tokens and ID tokens are short-lived. Since you are using the Authorization-Code Grant flow of OAuth, after they expire, you must refresh them to continue to access resources .
Hence in order to get the refresh-token, you would have to send a POST request to the /token endpoint of B2C with the scope .(i.e; Provide the refresh_token instead of the code in the rquest).see reference 1.
Make sure to add scopes along with AppId 'openid profile offline_access AppId’
Ex: scope: 'openid profile offline_access XXXXXX-f9a4-4b8e-XXXX-dXXXXXXX01f'
References:
Authorization code flow - Azure Active Directory B2C | Microsoft
Docs
microsoft-authentication-library-for-js/FAQ (github.com)
The disturbing scenario is: users log out of the application but their session remains valid such that they are able to sign back in without reauthenticating. Is the below code snippet the portion of the code that needs to be configured for the B2C session behaviour?
app.UseRewriter(
new RewriteOptions().Add(
context =>
{
if (context.HttpContext.Request.Path == "/MicrosoftIdentity/Account/SignedOut")
{ context.HttpContext.Response.Redirect("/Home/Index"); }
}));
When you want to sign the user out of the application, it isn't enough
to clear the application's cookies or otherwise end the session with
the user. Redirect the user to Azure AD B2C to sign out. If you fail
to do so, the user might be able to reauthenticate to your application
without entering their credentials again
The logout endpoint can receive an optional post_logout_redirect_uri parameter in the query string, where you can specify another URL where your user will be finally redirected by B2C. That can be the address of any resource, e.g. you homepage or your own page showing a "You successfully logged out of our service" message to the user.
post_logout_redirect_uri - The URL that the user should be redirected to after successful sign out. If it isn't included, Azure AD B2C shows the user a generic message.
For more details refer this document And also check with this SO Thread
I have an implementation of IdentityServer4 which connects with Azure AD for authentication (OIDC). In the callback method, using the IdentityServertools, I am generating the access_token and redirecting the user to SPA with the same. The SPA then stores the access_token into localstorage and uses it for authentication.
Normally, when my SPA app hits the token endpoint of the IdentityServer4, it gives access_token and refresh_token and then uses refresh_token to re-authenticate a returning user.
In this case of SSO with Azure AD, do I need to generate refresh_token manually? If yes, I can build on top of default implementation and that's not the problem (However, the docs suggest against of changing the IRefreshTokenService implementation or building something from scratch)
My real question is, is there a need of refresh_token here? Because refresh_tokens are stored in DB and never get's deleted and after sometime, these refresh_tokens table will swell (right now it already has 80k rows). The user is expected to click on a small tile inside SAP's Successfactor - that will open the signin/consent screen of Azure or will directly take the user to the main page where zhe will just answer a question and done. So it's hardly 2-3 mins business. So I can continue to generate access_tokens from my IdentityServer4 for every click as I don't expect the user to stay authenticated in the browser if zhe has logged out from SAP's Successfactor (or any other app linked with Azure).
Please advise, if I should generate refresh_token? Is it a good architecture?
Access token is used to prove the request is allowed to access the resource(such as api from ms or your custom api) and refresh token is used to refresh access token to make sure the access token isn't expired. Access token will expire in an hour by default and refresh token has 90 days.
At this point, we can easily find the refresh token is designed for some special scenarios because the expired time for refresh token is much longer than access token's expired time, but we can also generate a new access token in other way such as using msal or sign in again.
As you said in the question, you can generate an access token by one click and you don't expect users to stay authenticated for a long time. So I think it's unnecessary for you to use refresh token.
I am using MS Graph in a desktop application so I am hosting a web browser in a form for the user to do their initial login. This all works fine and I can fully use MS Graph.
The problem I have is if we need to use an account of a different user there does not seem to be a way to reset the login. If you try to login again with the hosted web browser it will go right through and allow the same user.
The only way to reset it for another user seems to be to go into IE and delete the history/cache. Then the login screen will ask a user to login again. It seems a bit extreme to reset the cache.
So is this the only way to do this or is there something I can change in the MS Graph API call to tell it to reset?
You can force re-authentication by added prompt=login to the sign-in request:
Prompt (optional)
Indicates the type of user interaction that is required. The only valid values at this time are login, none, select_account, and consent.
prompt=login will force the user to enter their credentials on that request, negating single-sign on.
prompt=none is the opposite - it will ensure that the user isn't presented with any interactive prompt whatsoever. If the request can't be completed silently via single-sign on, the Microsoft identity platform endpoint will return an error.
prompt=select_account sends the user to an account picker where all of the accounts remembered in the session will appear.
prompt=consent will trigger the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.
We're working on a SAAS application that has recently been configured to use Azure ADAL for authentication. If it matters, we're going the oauth2 route, with response_type: code.
However, when we're testing the application, if the browser has been signed into an Azure account that does not belong to the tenant acting as identity provider, the prompt for password is bypassed, and the login fails on the Azure screen, saying AADSTS50020 - user not found in tenant.
On the one hand, congratulations to Azure for finding an already signed in user! On the other hand, there is no recourse to elect to not use this signed in user; it does not give the user the chance to interject with credentials that work.
How can we prevent this?
The core issue is we don't want users, visiting our site and ready to sign in, to have to have already signed out of Azure before trying to log in with our site.
Thanks in advance.
Please refer to https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
You could find when requesting an authorization code during code flow , there is a Parameter :prompt indicates the type of user interaction that is required .
Valid values are:
login: The user should be prompted to reauthenticate.
select_account: The user is prompted to select an account, interrupting single sign on. The user may select an existing signed-in account, enter their credentials for a remembered account, or choose to use a different account altogether.
consent: User consent has been granted, but needs to be updated. The user should be prompted to consent.
admin_consent: An administrator should be prompted to consent on behalf of all users in their organization
You could use prompt=login forces the user to enter their credentials on that request, negating single-sign on