azure.identity.InteractiveBrowserCredential: good/bad token depends on calling order

[rfernand2]

azure-identity==1.2.0
azure-keyvault-secrets==4.0.1
Windows 10
python 3.6.10

After creating a credential object from InteractiveBrowserCredential(), if I immediately call credential.get_token(), then the returned token can successfully be used with Microsoft Graph API.

However, if I first use the credential for a SecretClient get_secret() call, and then do the credential.get_token() call, the returned token cannot be used with Graph API - the following error is returned:

"{'error': {'code': 'InvalidAuthenticationToken', 'message': 'Access token validation failure. Invalid audience.', 'innerError': {'request-id': '09fc35e4-56ba-4740-a993-a0379c5ca524', 'date': '2020-03-10T21:03:23'}}}"

My Graph API call:

    endpoint =  "https://graph.microsoft.com/v1.0/me"
    headers = {'Authorization': 'Bearer ' + token}

    graph_data = requests.get(endpoint, headers=headers).json()
    upn = graph_data["userPrincipalName"]

Expected behavior
I expect the Graph API to work, independent of when I call get_token().

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Not a blocking problem, but seems related to another problem where, when using
DeviceCodeCredential(), the call to get_context() requires a 2nd authentication.

[chlowell]

Access tokens are scoped to resources. A token for Key Vault isn't valid for Graph. You're sending Key Vault tokens to Graph. Here's why:

1. get_secret provokes a request for a Key Vault access token
2. that access token is cached
3. you call get_token(), specifying no scope
4. the cache searches for an access token matching the requested scopes
5. You didn't specify any scope. By the cache's logic, any access token matches.
6. the cache returns the Key Vault token

It works the other way round, Graph then Key Vault, because SecretClient specifies the Key Vault scope every time it calls get_token. Also, when you call get_token() with no scope, the code which ultimately requests the token (it doesn't live in azure-identity) chooses default scopes for you. Those defaults evidently satisfy the Graph APIs you use.

Which is all to say you should be able to solve this problem by specifying the Graph scopes you need in your get_token calls.

Thanks for opening this issue. I hadn't previously considered the consequences of calling get_token(), because service clients in the SDK never do it (get_token was designed for them alone). I think default scopes are more confusing than helpful, so get_token should force callers to be specific about what they're requesting access to. It should raise an error when no scope is specified.

[chlowell]

Thanks again for opening this issue. I'm closing it as resolved by #10366.