Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QUERY] Identify token source for DefaultAzureCredential #17730

Closed
luckerby opened this issue Jan 3, 2021 · 3 comments
Closed

[QUERY] Identify token source for DefaultAzureCredential #17730

luckerby opened this issue Jan 3, 2021 · 3 comments
Assignees
Labels
Azure.Identity Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention Workflow: This issue needs attention from Azure service team or SDK team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that

Comments

@luckerby
Copy link

luckerby commented Jan 3, 2021

When calling one of the methods to obtain a token against a DefaultAzureCredential instance, multiple credential types will be tried, in order, as specified here. Once a token is obtained - from one of the credentials that were cycled through - is there a way to find out which type of credential "won"?

An example: suppose when calling DefaultAzureCrendetial's GetTokenAsync method, it's the SharedTokenCacheCredential that is able to retrieve one such token. Would one be able to determine that it was indeed a SharedTokenCacheCredential that generated that token (eg either by looking at the DefaultAzureCrendetial object, or on the resulting Azure.Core.AccessToken result?

I had a look at the code, and also debugged a bit, but wasn't able to come up with anything useful. I briefly thought about catching the exceptions that each credential might generate when GetToken/GetTokenAsync isn't successful, but it appears those are not surfaced to the user's calling code.

There's an SO thread here that asks a similar question, albeit for Python. It appears that there doesn't seem to be a solution there as well, aside from building a wrapper yourself using each type of credential.

@ghost ghost added needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. customer-reported Issues that are reported by GitHub users external to the Azure organization. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Jan 3, 2021
@jsquire jsquire added Azure.Identity Client This issue points to a problem in the data-plane of the library. needs-team-attention Workflow: This issue needs attention from Azure service team or SDK team labels Jan 4, 2021
@ghost ghost removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Jan 4, 2021
@jsquire
Copy link
Member

jsquire commented Jan 4, 2021

Thank you for your feedback. Tagging and routing to the team best able to assist. Please be aware that due to the holidays, responses may be delayed.

@jongio
Copy link
Member

jongio commented Jan 22, 2021

Related: #8948

See that issue for a workaround with AzureEventSourceListener

@christothes
Copy link
Member

Will track this in the linked #8948

@github-actions github-actions bot locked and limited conversation to collaborators Mar 28, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Azure.Identity Client This issue points to a problem in the data-plane of the library. customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-team-attention Workflow: This issue needs attention from Azure service team or SDK team question The issue doesn't require a change to the product in order to be resolved. Most issues start as that
Projects
None yet
Development

No branches or pull requests

5 participants