-
Notifications
You must be signed in to change notification settings - Fork 205
acquire_token_interactive(..., prompt="none") acquires token via Cloud Shell's IMDS-like interface #420
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
Conversation
f82a447
to
234bd5a
Compare
234bd5a
to
072436b
Compare
072436b
to
f8f6d69
Compare
self.token_cache.add(dict( | ||
client_id=self.client_id, | ||
scope=response["scope"].split() if "scope" in response else scopes, | ||
token_endpoint=self.authority.token_endpoint, | ||
response=response.copy(), | ||
data=data or {}, | ||
authority_type=_AUTHORITY_TYPE_CLOUDSHELL, | ||
)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Cloud Shell's pseudo managed identity endpoint already has a cache, so does a normal managed identity endpoint. Do we really need to save it to MSAL's cache?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The devil is in the details.
I think Cloud Shell's pseudo managed identity endpoint already has a cache,
The SSH Cert feature has its own quirk in caching. Currently, the Cloud Shell (actually the Azure Portal) does not yet really support caching for SSH Cert.
so does a normal managed identity endpoint.
Yes but there is a catch. Quoted from normal managed identity's document: "The managed identities subsystem caches tokens but we still recommend that you implement token caching in your code." They even defined an HTTP 429 throttling error when you use Managed Identity endpoint too often. FWIW, I'm currently working on another project that is trying to enable MSAL token cache for managed identity.
Do we really need to save it to MSAL's cache?
The MSAL cache has long been designed to be used as often as you want, and it also stores SSH cert. Adding this (technically still a) one-liner here can allow existing MSAL-powered apps' acquire_token_silent()
to work, for free (meaning without any extra code change in app's code). Why not?
Cloud Shell Detection PoC: Silent flow utilizes Cloud Shell IMDS Introduce get_accounts(username=msal.CURRENT_USER) A reasonable-effort to convert scope to resource Replace get_accounts(username=msal.CURRENT_USER) by acquire_token_interactive(..., prompt="none") Detect unsupported Portal so that AzCLI could fallback
The changes in this proof-of-concept is to allow a typical 3-step pattern MSAL app to automatically utilize the IMDS-like interface when that app happens to be running inside Cloud Shell.
Note to target audience (@jiasli ):
https://rc.portal.azure.com/?feature.sshtokens=true&feature.tokencaching=false#home
Currently, portal and Cloud Shell team are still working on the error handling, but that part does not block Azure CLI from integrating this feature branch.
https://management.core.windows.net/,https://management.azure.com/,https://graph.windows.net/,...