My application uses Azure B2C to authenticate users (Custom policies). Some users are often (some times several times a day) asked to re-authenticate when navigating the website (built with react). But some are not, and never have to re-authenticate (refresh token mechanism working as expected). Token management is done using microsoft MSAL library without any fancy customization.
My question is: how can I log/know (probably directly on the Azure B2C portal) the reasons why B2C invalidates the tokens in the first place? Is there such a feature on the Azure portal?
In JS apps, the refresh token is fixed at 24hrs.
The AAD B2C web app session cookie (fallback after RT expires), has a maximum length of 24hrs.
AAD B2C doesn't invalidate refresh tokens, they can only expire. Refresh tokens are only invalidated if your application/service explicitly calls the refresh token revocation Graph API endpoint.
In your case, it is extremely likely that users are using the app after 24hrs of last logging in.
You can offer Keep-Me-Signed-In option so users can have a long lived session cookie.
Related
Currently Azure AD B2C issues a refresh token that is valid for 24 hours (non-configurable, non-renewable) for single page apps that use the PKCE code flow.
When that 24 hours is expired from the initial sign in the user needs to reauthenticate with the AD B2C. If the browser has been closed during that time the AD B2C session is lost and now user must interactively reauthenticate. I don't understand how this could be acceptable default user experience for most web apps.
Is there any way to work around this? Perhaps a way to make the AD B2C session persistent so that it survives browser closes and full interactive reauthentication is avoided. I don't want to have the only web app in the universe that requires the user to sign in again every 24 hours.
Edit:
We're using external identity providers so KMSI for local accounts doesn't really help.
You can use keep me signed in to extend the users Azure AD B2C session lifetime.
Please Refer:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-keep-me-signed-in
Update:
The Azure AD B2C Session Cookie will always be evaluated first to determine if the user should be sent back to their federated IdP to do a new authentication. Only when both the Azure AD B2C session cookie and the federated IdPs session cookie are expired, will the user have to re-enter their credentials at the federated IdP.
To prevent the user having to go back to the federated IdP to authenticate, you can raise the AAD B2C session cookie lifetime beyond that of the federated IdP session cookie lifetime.
When using Custom Policy, you can use the Session Management technical profile to make sure the federated IdP authentication is part of the session itself.
See how we did this for the Google IdP with the use of SM-SocialLogin:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-custom-setup-goog-idp#add-a-claims-provider
<UseTechnicalProfileForSessionManagement ReferenceId="SM-SocialLogin" />
Add this line to the federated IdP technical profile to make sure its part of the AAD B2C session.
Once you are app is closed you may need to login again, because your app cookes is not persisted.
You could maintain a cookie set by the app to automatically send the user via the login endpoint if they had signed in previously with KMSI. You can use a claims resolver to send the KMSI claim into the token so your app can understand the user logged in with KMSI. https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview
SessionExpiryType/SessionExpiryInSeconds - not related to KMSI cookie. Relates to B2Cs normal SSO Cookie.
KeepAliveInDays - KMSI Cookie lifetime.
Please see this document for more clear information
https://learn.microsoft.com/en-us/azure/active-directory-b2c/relyingparty#userjourneybehaviors
I am using vue-adal library in my VueJS application to connect to Azure AD.
AD Token valid for 1hr after login.
When my token expires i am unable to renew it from client side.
Is there any way to renew token from client side using VueJS or
Any other alternate approach can be used for this scenario?
Thanks,
Gowtham
Since you are using implicit flow, azure AD will not return refresh token in implicit flow for you to refresh the token. As per this documentation, here is the recommended approach for this.
A JavaScript application has another mechanism at its disposal for
renewing access tokens without repeatedly prompting the user for
credentials. The application can use a hidden iframe to perform new
token requests against the authorization endpoint of Azure AD: as long
as the browser still has an active session (read: has a session
cookie) against the Azure AD domain, the authentication request can
successfully occur without any need for user interaction.
Is it possible to establish Azure AD SSO/session (with all required cookies) having only Access/ID tokens obtained using ADAL library?
Our scenario is quite similar with one described here:
We have Cordova app with ADAL library as plugin. We managed to authenticate users and get Access/ID tokens using ADAL. Then we initiate SAML SSO between Azure AD and our backend. It works fine the first time user authenticates using ADAL since it's popups microsoft login screen and after successful authentication it establishes a session with Azure AD. But when user logs out our app clears all cookies and next time ADAL gets's tokens from cache and does not provide the login screen which is OK. The problem is that SAML SSO does not work after that since session is gone (no cookies).
I know that ADAL is not quite designed to work with SAML, but maybe there are some dirty or not dirty workarounds to establish session with Azure AD having only access or id tokens?
No, it is not possible.
To get the session cookies, the user must login by themselves.
You can assist the user in logging in to the right account by specifying their AAD tenant id in the authority URI (instead of common), and by specifying login_hint=username#company.com with their user principal name in the authorization call as an extra query parameter.
They should then only need to enter their password (+ MFA etc.)
I'm not sure I'm understanding this properly, but here goes:
Since MSA and Google tokens expire every hour, the only way for my app to reflect changes in the user's permissions on the MSA and Google site would be to refresh the EasyAuth B2C token on roughly the same interval, right? If they revoke access to my app, then they probably don't want unexpired tokens rolling around for days.
And each time I need to refresh that token, another refresh call is made to B2C and then on to the identity provider, right?
And each time that happens I'll be charged (based on the info on the Azure pricing page). So if my app (it's a financial app with the ability to charge credit cards) gets popular and scales, the fees will be actually quite large, as there will be tons of logging in/out and refreshing if everyone is responsible.
Do I have this right? Any suggestions for mitigating the fees responsibly?
Does the refresh token store get purged when someone logs out? If so, then I could just assume (I know - bad word) that if they want to disable access to the app, they just logout. Any subsequent login or use of a refresh token would then be blocked.
Since MSA and Google tokens expire every hour, the only way for my app to reflect changes in the user's permissions on the MSA and Google site would be to refresh the EasyAuth B2C token on roughly the same interval, right?
Based on my understanding, web application used the id_token to authenticate the user. After the web application authenticated, it contains its own session and the default web application session time is 1440 minutes, we can config it. You can refer here for the detail.
And if you were using the OAuth 2.0 flow to authorize the application to access the resource which protected by Azure AD, since the life time of token is one hour if it is expired we need to renew the token as you mentioned.
And each time I need to refresh that token, another refresh call is made to B2C and then on to the identity provider, right?
And each time that happens I'll be charged (based on the info on the Azure pricing page). So if my app (it's a financial app with the ability to charge credit cards) gets popular and scales, the fees will be actually quite large, as there will be tons of logging in/out and refreshing if everyone is responsible.
Do I have this right? Any suggestions for mitigating the fees responsibly?
You were right. Azure Active Directory (Azure AD) B2C usage will be billed monthly based on the total number of both: Stored Users, Authentications: Tokens issued either in response to a sign-in request initiated by a user, or initiated by an application on behalf of a user (e.g. token refresh, where the refresh interval is configurable).
Does the refresh token store get purged when someone logs out? If so, then I could just assume (I know - bad word) that if they want to disable access to the app, they just logout. Any subsequent login or use of a refresh token would then be blocked.
Did you mean revoke the token? The log out the web application won’t revoke the token. Azure AD doesn’t support revoking the token at present. However, we can clear the token cache if you doesn’t want users to user the token.
I have a question about how to get and then use a refresh token when accessing a Microsoft Azure Mobile service that has been secured.
I am building a mobile app and right now have the basics of this working. I can authenticate against azure ad and windows account (will a few more later) all provided by azure mobile services. to do this I use the Mobile client and mobile service user. I can then store the login ticket in windows phone 8 and IOS. will add android when I figure out the key chain in android. but what I need to figure out is how to get a refresh token and then what to do with it. right now my logins expire after 1 hour
I found the answer to this when Microsoft added it. I found the
post to be very helpful:
http://cgillum.tech/2016/03/07/app-service-token-store/
This is the main bit of the post
Refreshing Tokens
An important detail about using access tokens is that most of them will eventually expire. Some providers, like Facebook, have access tokens which expire after 60 days. Other providers, like Azure AD, Microsoft Account, and Google, issue access tokens which expire in 1 hour. In all cases, a fresh set of tokens can be obtained by forcing the user to re-authenticate. This is reasonable for Facebook since a re-auth would only need to happen once every 60 days. However, this is not practical for Azure AD, Microsoft Account, and Google, where the token expiration is 1 hour.
To avoid the need to re-authenticate the user to get a new access token, you can instead issue an authenticated GET request to the /.auth/refresh endpoint of your application. This is a built-in endpoint, just like /.auth/me. When called, the Easy Auth module will automatically refresh the access tokens in the token store for the authenticated user. Subsequent requests for tokens by your app code will then get the most up-to-date tokens. In order for this to work, the token store must contain refresh tokens for your provider. If you’re not familiar with how to do this, here are some hints:
Google: Append an “access_type=offline” query string parameter to your /.auth/login API call (if using the Mobile Apps SDK, you can add this to one of the LogicAsync overloads).
Microsoft Account: Select the wl.offline_access scope in the Azure management portal.
since this has been added I have been able to work with Microsoft account and refresh as I need to