[BUG] Access token parsing failed

[ritishgoyal]

Describe the bug
When I try to get an access token for an external resource using Client certificate token provider by using AzureServiceTokenProvider.GetAccessTokenAsync(), I receive an error saying the access token couldn't be parsed.

Expected behavior
We should not try to parse the access token since it is not in the format expected.

Actual behavior (include Exception or Stack Trace)
Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProviderException: Parameters: Connection String: RunAs=App;AppId=e165870b-8f4f-48ad-951f-2752be329850;TenantId=cdc5836a-15c5-4db6-b079-fcadd2505dc2;CertificateSubjectName=CN=sp.m365insidexxxxx.gbl;CertificateStoreLocation=CurrentUser, Resource: api://04cbdc38-6aaf-4668-bc55-b12e857433, Authority: https://login.microsoftonline.com/cdc5836a-15c5-4db6-b079-fcadd2505dc2. Exception Message: Tried 1 certificate(s). Access token could not be acquired.
Exception for cert #1 with thumbprint 6E199A1F059912D67xxxxx: Access token is not in the expected format. Exception: There was an error deserializing the object of type Microsoft.Azure.Services.AppAuthentication.AccessToken. Encountered unexpected character 'w'.
at Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProvider.d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.Azure.Services.AppAuthentication.AzureServiceTokenProvider.d__21.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()

To Reproduce
var azureServiceTokenProvider = new AzureServiceTokenProvider($"RunAs=App;AppId={"xxxxx"};TenantId={"zzzz"};CertificateSubjectName=CN={"xxxx"};CertificateStoreLocation=CurrentUser");
string token = await azureServiceTokenProvider.GetAccessTokenAsync("https:\resourcexx")

I was able to fix the issue by removing line 197: PrincipalUsed.TenantId = AccessToken.Parse(accessToken).TenantId; from ClientCertificateAccessTokenProvider.cs
So, the issue is that the returned access token is not in the format expected by the library but is still a valid token.

Environment:

• Name and version of the Library package used: Microsoft.Azure.Services.AppAuthentication 1.6.1
• Hosting platform or OS and .NET runtime version (dotnet --info output for .NET Core projects): .NET Framework 4.6.3

[jsquire]

//cc: @nonik0, @anaismiller

[jsquire]

Thank you for your feedback. Tagging and routing to the team members best able to assist.

[anaismiller]

@ritishgoyal What are you trying to use the certificate for? Is is a supported scenario?

[ritishgoyal]

@anaismiller I am trying to get a token for an external azure resource using s2s App ID based auth with an App ID and certificate.
It should be a valid scenario since the token fetched succeeds in authorization for my s2s calls, only if I remove the parsing logic which is throwing an error. I am thinking of raising a pull request for making the token parsing to get tenantID optional.

[ritishgoyal]

Can you provide an update on this?

[nonik0]

@ritishgoyal Thanks for pointing this out and sorry for the delay. While I am not sure about the specifics of your scenario, it does like like you're getting a non-standard token from AAD (are your access tokens being encrypted?). We do have some non-ideal code that parses the token from AAD to get tenant ID info, but this is not strictly necessary. It's generally not good practice either to "look" at access tokens in code, and should rather be treated opaquely.

I can discuss options with the team but so far your suggestion of making the tenantID parsing logic optional (i.e. eat parsing exception) is the best option so far IMO.

[ritishgoyal]

I'm not sure why the access token is non-standard. I'm getting it from the AAD production endpoint.
Yes, I think eating the parsing exception is the right call. Can you follow up on this with your team and get a fix in soon.
I'm kind of blocked on this and currently using a custom compilation of the library to get around this. Thanks!