AzureAD
[Question] Cookie expiration versus ID Token expiration
Which version of Microsoft Identity Web are you using? Microsoft Identity Web + UI - 1.22.2
Where is the issue?
- Web app
- [x] Sign-in users
- [ ] Sign-in users and call web APIs
Azure B2C used as an IdP. Sample app taken from here - https://github.com/Azure-Samples/active-directory-aspnetcore-webapp-openidconnect-v2/tree/master/1-WebApp-OIDC/1-5-B2C
Simple scenario when Microsoft.Identity.Web is just used for authenticating users (no downstream API calling) so the response_type is id_token only.
Looking at the response the ID Token is valid for 1 hour.
In the MS docs I've read in several places that expiration of ID Token should/can be used to control how often the client application expires the application session.
https://docs.microsoft.com/en-us/azure/active-directory/develop/id-tokens#id-token-lifetime
By default, an ID token is valid for one hour - after one hour, the client must acquire a new ID token.
You can adjust the lifetime of an ID token to control how often the client application expires the application session, and how often it requires the user to re-authenticate either silently or interactively. For more information, read Configurable token lifetimes.
https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-configurable-token-lifetimes#id-tokens
ID tokens are passed to websites and native clients. ID tokens contain profile information about a user. An ID token is bound to a specific combination of user and client. ID tokens are considered valid until their expiry. Usually, a web application matches a user’s session lifetime in the application to the lifetime of the ID token issued for the user. You can adjust the lifetime of an ID token to control how often the web application expires the application session, and how often it requires the user to be re-authenticated with the Microsoft identity platform (either silently or interactively).
But in the default configuration for Microsoft.Identity.Web & Microsoft.Identity.Web.UI in the scenario for just authenticating the users, the session cookie has the Session expiration so I think I can use this cookie as long as I keep my browser open and it will outlive ID Token.
What are the best practices and recommendations here?
From one side expiring cookie with ID Token would make it more secure as for example the user might have been disabled/deleted on the B2C side in the meantime and he won't be able to authenticate again.
On the other side if we expire cookie with ID Token the legit user would be redirected to B2C login page more often which may interrupt his work in the client application - even if he still has active SSO cookie on the B2C side. Unless there are any ways to request new ID Token silently? Similar how we can silently access new access token using refresh token.
Im running into the same issue. And i think the AzureAD docs regarding code authorization flow and the obo flow to aquire tokens for downstream api's are creating false expectations of this library. This is due to a lack of clear documentation.
Its documented that when doing the code auth flow, a refresh token is returned when you have granted offline_access for logging into the application. In my case its granted for all users in the organisation by the Admin. This refresh_token is not exposed by the CCA but instead stored internally and subsequent calls to AquireTokenSilently should check the lifetime of the accesstoken and use the refreshtoken to aquire a new one if needed.
This all works insofar one can verify this. But after 1 hour when the id_token expires, everything stops working. The user then MUST login anew to refresh its id_token else the OnBehalfOf tokens aquired will also stop working.
There is a misunderstanding between id_tokens and access_tokens. When using this library its expected that the relevant tokens are refreshed. Buts the one token that really matters, the id_token, is never refreshed automatically or silently.
This can easily be tested by configuring the openIdOptions.UseTokenLifetime to be false when calling AddMicrosoftIdentityWebApp.
In my case im using this libraries Owin variant for an internal application. And i dont want to force my users into a login redirect every hour or so. I am not the only one running into this problem. I have found several stack overflow issues which outright run into the same problem, or are related to this fundamental issue. Also when asking around in the community almost everyone i talk to have rolled their own implementation to work around this issue. Often opting to completely handle id and accesstoken in the browser and only send a bearer token to the server in combination with a custom auth handler, even in non-SPA situations. I think this is a strong indicator that at the very least more documentation regarding the webapp scenario is required. Explaining why its not supported. But ideally this library would help us handling that type of scenario.
