SQL Token Cache Provider Has Trouble Handling Different Client Applications Using the Same User Token Cache Record

[Alfetta159]

Please provide us with the following information:

This issue is for a: (mark with an x)

- [X] bug report -> please search issues before submitting
- [ ] feature request
- [ ] documentation issue or request
- [ ] regression (a behavior that used to work and stopped in a new release)

The issue was found for the following scenario:

Please add an 'x' for the scenario(s) where you found an issue

1. Web app that signs in users
   1. with a work and school account in your organization: 1-WebApp-OIDC/1-1-MyOrg
   2. with any work and school account: /1-WebApp-OIDC/1-2-AnyOrg
   3. with any work or school account or Microsoft personal account: 1-WebApp-OIDC/1-3-AnyOrgOrPersonal
   4. with users in National or sovereign clouds 1-WebApp-OIDC/1-4-Sovereign
   5. with B2C users 1-WebApp-OIDC/1-5-B2C
2. Web app that calls Microsoft Graph
   1. Calling graph with the Microsoft Graph SDK: 2-WebApp-graph-user/2-1-Call-MSGraph
   2. With specific token caches: 2-WebApp-graph-user/2-2-TokenCache
   3. Calling Microsoft Graph in national clouds: 2-WebApp-graph-user/2-4-Sovereign-Call-MSGraph
3. Web app calling several APIs 3-WebApp-multi-APIs
4. Web app calling your own Web API
5. Web app restricting users
   1. by Roles: 5-WebApp-AuthZ/5-1-Roles
   2. by Groups: 5-WebApp-AuthZ/5-2-Groups
6. Deployment to Azure
7. Other (please describe)

Repro-ing the issue

Repro steps

Create facsimile apps but with more than one web client application that uses the same SQL user token cache table (i.e. more than one Azure registered client app ID.)

Run one client application and log on with a particular work account, then run the other client application and log on with that same account.

Expected behavior

Both apps should allow me to log on via that single signed on account.

Actual behavior

The second application to try logging on throws a encryption exception at

args.TokenCache.DeserializeMsalV3(tokenCacheBytes, shouldClearExistingCache: true);

MSALAppSqlTokenCacheProvider.cs, line ~184

Possible Solution

In ClaimPrincipalExtension.cs, add the application ID to the Msal Account ID to differentiate which application wrote to the UserTokenCache table.

public static string GetMsalAccountId(this ClaimsPrincipal claimsPrincipal)
{
	string userObjectId = GetObjectId(claimsPrincipal);
	string tenantId = GetTenantId(claimsPrincipal);
			
	// Same as GetObjectID, but look for claimtype == "aud"
	var applicationId = GetApplicationId(claimsPrincipal);
	if (!string.IsNullOrWhiteSpace(userObjectId) && !string.IsNullOrWhiteSpace(tenantId))
	{
		return $"{userObjectId}.{applicationId}.{tenantId}";
	}

	return null;
}

Update:

My suggested solution is not very good in that the aud claim isn't present during logging out. I'm working around this by adding the claim to the User during the OnRedirectToIdentityProviderForSignOut event just before calling the RemoveAccount method. I'm curious to see if the problem lies elsewhere first.
Additional context/ Error codes / Screenshots

Any log messages given by the failure

Add any other context about the problem here, such as logs.

(N/A)

OS and Version?

Window 10, VS 2019, .NET Core 2.2

Versions

ASP.NET Core 2.2

Attempting to troubleshooting yourself:

• did you go through the README.md in the folder where you found the issue?
• did you go through the documentation:
  • Scenario: Web app that signs in users
  • Scenario: Web app that calls web APIs

Mention any other details that might be useful

---

Thanks! We'll be in touch soon.

[TiagoBrenck]

Hello @Alfetta159,

Thanks for pointing that out. I am working to fix it, but in the meantime you can read this doc, that explains how to share DataProtection between apps.

There is another improvement that I am waiting to be finished to open the PR for this issue, but if you apply the SetApplicationName() sharing the same value on both apps, the exception is not thrown (you might face MsalUiRequiredException though, which is part of the improvement that I am waiting).

Thanks

[TiagoBrenck]

Fixed

[Alfetta159]

I'm still having a problem with this, and the problem is exacerbated by having services call other services using on behalf of flow while those apps are all hosted in Azure as all of the different Azure app services are effectively different machines so an app might call a api and then when another app or even api calls that service, I get the cryptography error. I'll try the work around or turn off sql caching for now, but this issue shouldn't be considered closed. Thanks everyone.

[TiagoBrenck]

Hi @Alfetta159,
Did you configure SetApplicationName() with the same name to all of these apps?

[Alfetta159]

I have been trying this w/ a couple of web app/web API application pairs, but not having and success in Azure just locally hosted.

I am going to take a little time and use the sample application and api and create two sets that talk to the same database and deploy them to Azure. I have the Microsoft.Web.Identity forked locally and deployed as a NuGet package on our private server. By stepping back from that and using the sample code, adding SQL caching, and two sets of app/api pairs using the same database, I can be more sure that I'm not doing something else wrong.

I will let you know how it goes. Thanks

[TiagoBrenck]

Ok, thanks.

[Alfetta159]

I spent some time this afternoon and evening setting up the #4 sample with a replicated pair using the same sql cache and published it all to Azure. It is still giving me the cryptographic error. Right now, the app registrations are using my company's tenant, but I could switch it to common and/or give you access to the resource group in Azure. Also, I could push the branch that I set this up in locally. Let me know. I'm happy to help (or find out if I'm doing something wrong!)

[TiagoBrenck]

@Alfetta159 So, locally it is working, right? The problem happens when you deploy them to Azure?

[Alfetta159]

Yes. Works locally when everything is in IISExpress on the same machine, but not as app services in Azure.

I even went back and double checked and moved the data protection calls to execute before the IdentityWeb service extension methods in the ConfigureServices method of the StartUp.cs. I made sure that there isn't a corresponding call that needs to be made in the Configure method of the StartUp.cs. (Still wouldn't be surprised if I've missed something, however.)

I need to get back to my work here on my job. Everything seems okay w/ Session caching, so this isn't a show stopper for me. And again, let me know if any of the code or Azure deployments would be helpful to you.

[TiagoBrenck]

I have a testing setup that I could deploy on Azure, thanks though.
I will investigate it and let you know once we get a fix for this.

Thanks for the cooperation.