We have requirements for a Mobile Application AD B2C client that the user should only need to login once and the login session should never expire.
Is this possible with AD B2C? Is it from security perspective desired?
My findings so far:
I checked the configs and the maximum refresh tokem lifetime is 90 days. Which means if the App is not used for 90 days, the session ends. So my understanding is, it is not secure to keep a refresh token without expiry date.
Otherwise the "Keep Me Signed In" functionality could help, but that has probably also a maximum session length.
It is not possible today to achieve this due to the refresh token having at most a rolling 90 day expiration. Which means that the user needs to consume the application at least once every 90 days.
Keep Me Signed In has a maximum length of 68 years, but you would need to be using web based redirects rather than the resource owner password credential flow to take advantage of that. In such a case where the refresh token has expired, the app would redirect the user to login again, where the cookies would give the user SSO, and not prompt for any credentials.
If you are using am embedded webview style login, then KMSI will help.
if you are using API based logins (ROPC), then KMSI will not help, and you are reliant on the user using the app at least once per 90 days.
Security-wise, having no-expiry logins may not be the best approach but I've done it when the customer really insisted on it. Also, it is possible only if you have total control over the web services called by your app and you can modify them. You didn't specify if your app calls any web services, but most apps do so I presume that's your case too.
The key to never expire the user session in the app is to manage the application state (user logged-in or not) yourself, separately from the "B2C state". For example you can do it like this:
- At the first login, you call the B2C server for authentication. It will return an ID token.
- You pass the ID token to a web service/web API that validates it, then returns an "app token" to the app. The simplest form of app token is a GUID. Your back-end should keep track of all the issued app tokens, e.g. in a database.
- from this point on, all the subsequent API calls will be authorized using the app token; all the tokens issued by B2C are no longer needed and you should discard them
- at logout, you call the API to invalidate or delete the opaque token on your back-end. You should also try to logout from B2C, just in case the user session was short and the B2C session didn't yet expire.
Note: If you need access to third-party services that use Oauth2 and rely on the access tokens issued by B2C, this will obviously not work.
