Allow refreshing the token obtained by InteractiveBrowserCredential

[superhrusha]

The problem I am trying to solve:

• I am writing a desktop client app that will programmatically connect to Azure storages
• The app will be run by multiple stakeholders in the organization from their personal computers
• The storages contain sensitive information so I want to properly secure access- access should be based on AD, much like Azure CLI works.
• I have a working solution but the token I get expires in one hour.
• I want to provide a good UX. Requiring the user to interactively authenticate once an hour is unacceptable.
• As far as I know the standard way to deal with theses situations is by using the refresh token
• unfortunately, the refresh token is discarded by the InteractiveBrowserCredential.get_token method.

The solution I'd like
I would like the mechanism to allow me to refresh an expired token without bothering the user of the app.

Alternative I considered
override the get_token method and try to implement it myself by extracting relevant code. It would be hacky

[chlowell]

Hi @superhrusha, thanks for opening this. We're working on improvements to caching (tracked by #9744) and user authentication that will enable the solution you'd like in an upcoming release. I'll use this issue to track work around giving applications more control over how and when InteractiveBrowserCredential and other user credentials authenticate.

[superhrusha]

Thank you! Is there an ETA?

…

On Thu, Mar 12, 2020, 19:46 Charles Lowell ***@***.***> wrote: Hi @superhrusha <https://github.com/superhrusha>, thanks for opening this. We're working on improvements to caching (tracked by #9744 <#9744>) and user authentication that will enable the solution you'd like in an upcoming release. I'll use this issue to track work around giving applications more control over how and when InteractiveBrowserCredential and other user credentials authenticate. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10278 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGRJACAZAOJNMKGJGLJBELTRHENWZANCNFSM4LGPH3XQ> .

[chlowell]

User auth changes will roll out in beta releases over the next few months. I'll update this issue when something's available for feedback.

[superhrusha]

@chlowell, any chance you can recommend a workaround or a temporary solution, however hacky it maybe?
e.g - suppose I can get hold of the refresh token. How would I use it with the existing API?

[chlowell]

The public API never returns or accepts a refresh token, and we don't intend to change that. Any workaround involving getting or using one would therefore rely on private APIs which will soon change.

After rereading this issue I wonder whether I've misunderstood the problem. InteractiveBrowserCredential doesn't discard refresh tokens. If Azure AD provided one at the initial authentication, InteractiveBrowserCredential should redeem it when an access token expires. The token cache here is in-memory though, so all is lost when the process exits. Are you looking for a way to persist authentication across executions of your program, or have you observed multiple authentication prompts during a single execution?

[superhrusha]

The latter - persist across executions. I am looking to provide an experience similar to how Azure CLI works.
It persists the access token and the refresh token in a local file. This way it can be used across executions.

[chlowell]

Then we're on the same page. That persistence is the work in progress I mentioned above. If you need to implement your own persistence today, the best way is to write your own credential (the interface is simple).

If your users happen to be signed in to the CLI, there might be a workaround for you there. In the current beta of azure-identity (1.4.0b1) DefaultAzureCredential can use the Azure CLI's authenticated identity.