Skip to content

[Question] Token Caching Persistence on Linux #24356

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

Closed
jthughes opened this issue Apr 2, 2025 · 2 comments · Fixed by #24363
Closed

[Question] Token Caching Persistence on Linux #24356

jthughes opened this issue Apr 2, 2025 · 2 comments · Fixed by #24363
Assignees
Labels
Azure.Identity 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

Comments

@jthughes
Copy link

jthughes commented Apr 2, 2025

Hey there,

I've been trying to utilise the persistent/on disk cache feature of the azidentity package.

I'm unclear if my problems are a result of misunderstanding what is expected of a persistent cache, or if this is a problem with the package itself, but on Linux (I'm developing on Linux Mint) using the persistent cache retains the relevant tokens between different executions of the program, but does not persist across reboots.

Looking at the Linux implementation, a comment notes:

// Attempt to link a persistent keyring to the user keyring. This keyring is persistent in that
// its linked keys survive all the user's login sessions being deleted but like all user keys,
// they exist only in memory and are therefore lost on system shutdown. If the attempt fails
// (some systems don't support persistent keyrings) continue with the user keyring.

And looking at it, this is just a result of how keyctl on Linux works.

The token caching documentation lists Keychain and DPAPI as being the solutions for MacOS and Windows. I'm not set up for development on either of those operating systems, but my reading suggests that the persistent token cache using those implementations is more likely to persist across a reboot.

I guess my question is: Is the persistent token cache intended to persist across reboots?

If it is, then the Linux implementation does not achieve that.
If not, it could be useful to clarify the intent in the token caching documentation.

@github-actions github-actions bot added customer-reported Issues that are reported by GitHub users external to the Azure organization. needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. question The issue doesn't require a change to the product in order to be resolved. Most issues start as that labels Apr 2, 2025
@github-actions github-actions bot removed the needs-triage Workflow: This is a new issue that needs to be triaged to the appropriate team. label Apr 2, 2025
@chlowell
Copy link
Member

chlowell commented Apr 3, 2025

You've got it: in the best case, Linux caches are lost at shutdown because their encryption keys are stored in kernel memory. There are worse cases because the key retention service as a whole and some of its features are optional when compiling the kernel, and system configuration can make the service inaccessible to users. Unfortunately, this means you can't depend on persistent caching if you don't know all the systems your application will run on. This is why the persistent cache constructor tries to round-trip data through storage and returns an error if that fails for any reason.

I'm sorry this isn't already covered in the token caching doc. I'll update that.

@jthughes
Copy link
Author

jthughes commented Apr 3, 2025

Makes sense! Thanks for the efficient response and for the documentation update!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Azure.Identity 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
Projects
Development

Successfully merging a pull request may close this issue.

3 participants