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.
Related
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.
We are using Azure Active Directory B2C to authenticate users into our app, we use a user flow to let the user enter their credentials. after receiving the access token from azure we generate an app token that contain app related information.
we recently added the keep me sing in feature but it seems that there is no way to know in the response if the user has checked it or not? even the returned access token still expires after 60 minutes. this causes a problem for us since our app logs-out the user automatically after the token time's out. but if the user choose to stay signed in we want to stop this behaver. SO how can we tell if the user checked the keep me signed in?
I've read a lot in Microsoft docs and searched a lot with no luck to find a way!
the one thing I found was a KMSI attribute but it can only be added in custom policy's. witch is kinda hard to do now.. is there a way to get such an indicator from the user flow?
You can get the KMSI Boolean in the token using custom policies and claims resolvers.
https://learn.microsoft.com/en-us/azure/active-directory-b2c/claim-resolver-overview
However, this shouldn’t be needed in your scenario. When access token expires, the refresh token is used to redeem a new access token. If the refresh token is expired, then the B2C cookie is used to perform single sign on via the B2C login page.
The user is only logged out if all of the above are expired/invalidated.
More to read here What does KMSI in Azure B2C actually DO?
I have a file>new .net core web app which is using Azure AD for authentication which works fine out of the box.
I have a requirement to create some auth policies so I have the following code which check the groups in the users claims and sets up an "Admin" policy which I can use on my endpoints.
services.AddAuthorization(options =>
{
options.AddPolicy("Admin", policy => policy.RequireClaim("groups", "XXXXX"));
});
This works fine too. The problem is once the user is logged in, how can I:-
Revoke access if I needed to? (e.g. a user is removed from AD or has his access revoked)
Refresh the auth so that if there has been any change in claims, roles, groups etc, it is detected.
I took a look at https://learn.microsoft.com/en-us/azure/active-directory/enterprise-users/users-revoke-access but it doesn't give much. It actually says "It's possible that the app may never send the user back to Azure AD as long as the session token is valid."
How is the best way to handle this?
To summarize the comments and post as an answer:
As I said in the comments, if you need to revoke a user's access rights, then you can do this by revoking the user refresh token. After revoking the user's permissions in Azure, then revoke the refresh token and redirect the user to the login page.
After the user is authenticated, he will receive the access token and the refresh token.
First, you need to revoke the user's refresh token. The lifetime of the refresh token is 90 days by default, so you need to revoke it during its lifetime. You can use AAD Power Shell:
Revoke-AzureADUserAllRefreshToken -ObjectId "a1d91a49-70c6-4d1d-a80a-b74c820a9a33"
But as far as I know, the access token cannot be revoked. The default expiration time of the access token is 1 hour. After 1 hour, the user will automatically lose access to AAD.
If you want to terminate user access immediately after the user permissions is revoked, you can try the continuous access evaluation provided by Microsoft, which helps ensure invalidation of access tokens in near real time. However, as the documentation says, this may cause security issues, so I think it is not the best method.
So I think the best way is: just revoke the refresh token, and then wait 1 hour for the access token to expire, the user will automatically lose access to AAD. Then refresh the authentication and redirect the user to the login page.
I've got a user who signs in at 12 PM to an asset exchange using AAD for authentication. At 1 PM I discover that they're violating the exchange rules and I go into the Azure Portal and block the sign-ins for that user. As nearly as I can tell, this user's token is good for at least another hour. Is there any way to force a User out of the system without deleting his account?
You can disable the user's ability to sign in and access services in the Azure Portal. This will disable the user from signing in again or exchanging their refresh token for a new tokens.
Keep in mind, the user will still be able to access the resource as long as their access token is still valid (lifetime of 1 hour). To combat this, you can reduce the time of access tokens. Steps of how to change the lifetime.
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