Add sign-out functionality to MSAL

[DaRosenberg]

Please do correct me if I am wrong, but I have not been able to find any sign-out functionality in MSAL.

It would be useful to have something like a PublicClientApplication.SignOut() method to perform the following tasks:

• Remove cached tokens in MSAL
• Send a OIDC sign-out request to the tenant, in our case AAD B2C, to complete the sign-out (see here
• Remove all locally cached cookies, local storage entries, etc. from WKWebView belonging to the tenant hostname, in our case login.microsoftonline.com (see here and of course the equivalent on other platforms

It might make sense to have two overloads:

• PublicClientApplication.SignOut(IUser user) to do this for a given cached IUser
• PublicClientApplication.SignOut() to do it for all

I'm not sure about the technical feasibility of the former; for our scenario the latter would be perfect because we are only supporting one signed-in user at a time.

[bgavrilMS]

@DaRosenberg - thanks for the feedback, we are thinking of adding a feature to what you have described. Other ADAL libraries offer such functionality.

Note that MSAL does offer a mechanism to remove users from the token cache:

foreach (var user in App.PCA.Users.ToArray())
{
     App.PCA.Remove(user);
}

@jennyf19 - do you know if we document anywhere how to delete cookies from the system browser ?

Not sure about the OIDC sign out, need a bit more thought around the other Active Directories (@jmprieur )

[DaRosenberg]

@bgavrilMS Yep, we are already using the PublicClientApplication.Remove() method to clear the token cache, but as you know, this only gets us half way. :) Next user who wants to sign in with the same IDP will still be automatically signed in as the previous user, hence the need for clearing the WKWebView cookies etc.

We would do the cookie clearing ourselves, but the issue for us is that all the authentication stuff is implemented in a cross-platform library targeting netstandard2.0. To clear the WKWebView cookies we would need to add and co-ordinate with platform-specific code in the iOS app host project (different layer), hence it would be much better if MSAL handled this.

[Livven]

Unfortunately clearing cookies is impossible right now.

On Android, the use of Chrome Custom Tabs means that we don't have any control over cookies as they are shared with the external Chrome app and thus not accessible. The user would have to manually open the website in Chrome and then log out from any identity providers. Theoretically we could automatically open the logout URL, if one exists, but clearly that would be extremely bad UX.

On iOS, the library unfortunately does not use WKWebView but SFSafariViewController, which again does not allow access to its cookies. Since iOS 11 it no longer shares cookies with Safari either which makes the previous workaround impossible (see also this issue). However there is a new SFAuthenticationSession (deprecated and replaced with something similar in iOS 12) which does share cookies with Safari. See also #489.

So basically unless this library switches to embedded WebViews, automatic sign out of 3rd-party IdPs will be impossible. Instead we will have to provide instructions to users on how to do so manually.

[DaRosenberg]

@Livven The library has already switched to using WKWebView on iOS.

[jennyf19]

@DaRosenberg @Livven
We have embedded webview support in MSAL in our Combined repo. We are still working out a few things, but please try it out and let us know your thoughts/suggestions. We also updated to WKWebView for iOS.

[jmprieur]

Also, on the backlog we want to provide a good sign-out (which involves the service removing the cookie), and sign-out from device.

[mikerains]

Should be opt-in to participate in the shared cookie, and be able to log out and remove cookies for a specific tenant. Facilitate multiple directories and managing multiple identities across app.

[jmprieur]

Duplicate of #425

[jmprieur]

Closing as dupe of #425

[azav]

This appears to still be open as written in https://github.com/Azure-Samples/ms-identity-mobile-apple-swift-objc.

[jmprieur]

@azav @oldalton and @shoatman will confirm, but I believe that this is a slightly different scenario, where there is only one account on the device.
Which platform are you interested in, BTW? only Android and iOS? or also UWP/Windows desktop?

[DAConsulting]

Is there any solution to a "full" signout at this point?

[bgavrilMS]

You application does a "full" signout by calling RemoveAccount and removing any account info from its cache. Applications do not normally have control over browsers, this control is reserved for the user only. You wouldn't want some app that you sign out of to clear Chrome's cookies on your device.

In some very specific circumstances (embedded browser on Windows when using .NET classic), there are "hacks" to clear the cookies from it. You can look them up online, as we don't encourage this. But generally, there is no way to clear cookies from browsers installed by users and this activity should be left to the user.

For First Line Worker scenarios, where a device might be passed down from one worker to another at the end of shit, please try to use MSAL for Android / MSAL for iOS directly, as they support these scenarios. Is this your case?

[DAConsulting]

You application does a "full" signout by calling RemoveAccount and removing any account info from its cache. Applications do not normally have control over browsers, this control is reserved for the user only. You wouldn't want some app that you sign out of to clear Chrome's cookies on your device.

In some very specific circumstances (embedded browser on Windows when using .NET classic), there are "hacks" to clear the cookies from it. You can look them up online, as we don't encourage this. But generally, there is no way to clear cookies from browsers installed by users and this activity should be left to the user.

For First Line Worker scenarios, where a device might be passed down from one worker to another at the end of shit, please try to use MSAL for Android / MSAL for iOS directly, as they support these scenarios. Is this your case?

To be clear, I'm not looking for a hack. I am already clearing the cache using RemoveAccount. When I later invoke "AcquireTokenInteractive" the PublicClientApplication implemenation invokes an activity which redirects to the Azure sign on. Once there, despite the fact that I have cleared the token cache, Azure still "remembers" my password from a previous login. What I would expect is for Azure to force a prompt for a password at this point.

I do this to clear the cache (as illustrated in the examples I've seen):

IEnumerable<IAccount> accounts = await PCA.GetAccountsAsync();

            while (accounts.Any())
            {
                await PCA.RemoveAsync(accounts.FirstOrDefault());

                accounts = await PCA.GetAccountsAsync();
            }

I do this prior to invoking AcquireTokenInteractive:

AuthResult = await PCA.AcquireTokenInteractive(Scopes)
.WithAuthority(AUTHORITY_URI)
.WithParentActivityOrWindow(theParentWindow)
.ExecuteAsync();

What am I doing wrong (or NOT doing) that can force Azure to prompt for a password?

(Once again: if I manually clear the browser cache, then I get a prompt - but this should NOT be necessary).

Thanks for any insight.

[bgavrilMS]

Yeah, as I said, MSAL libraries can't control the browser cache. You do have some level of control over the interactive experience when using prompts - for example to force the user to re-enter their password, you can do:

AcquireTokenInteractive(scopes).WithPrompt(Prompt.ForceLogin);

A better way to deal with requirement however would be via Conditional Access. You ask the tenant admin to require users to enter their passwords at least once every x hours / days. Details at https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/howto-conditional-access-session-lifetime. From the developer perspective, when you call AcquireTokenSilent, MSAL will throw an MsalUiRequiredException and the user will have to re-enter their password.

[DAConsulting]

This is probably what I was looking for. Testing it now... Thank-you.

[DAConsulting]

Yup. I'll tell you... the docs on this stuff are VERY lean. I've been searching for "force login"... "force password prompt" and pouring over the MS docs for the past week (in between other tasks)... and found nothing.

Who would search for "conditional access session lifetime"? LOL!

At any rate. Thanks for your help!

[bgavrilMS]

Ha ha, yes, there is too much information to put in the docs. Don't hesitate to log a bug / question on MSAL repo, we will try to help.

[TheXenocide]

Wouldn't it be more appropriate for a sign out request to actually use the browser to tell Azure AD that it intends to sign the current user out (with token), so that Azure AD can also remove any service-side data associated with the issued token (e.g. invalidate the token so that if it has already been compromised it can no longer be used)? The response/handshake that takes place in the browser would be able to remove cookies from whatever system/embedded browser was used to sign the user in too, without any hacky manual cookie manipulation on the client-side.

We're migrating a mobile app right now that had sign out functionality built in previously when it was based around a custom identity broker which would delete the refresh token and such but the functionality doesn't appear to have an equivalent that we can map to during this migration to Azure AD without the broker. I know there's existing functionality in the Azure AD portal and Graph API to revoke refresh tokens, but it seems like it would be sensible to allow an application to intentionally request the refresh token that it acquired be revoked if it knows it should no longer be valid.

EDIT: oops, didn't see this ticket was closed. Comment reposted at #1593