[Feature Request] Use credential manager instead of local file store for token caching on Windows platforms

[azuread]

[Feature Request] Use credential manager instead of local file store for token caching on Windows platforms

[bgavrilMS]

Hi @brphelps,

MSAL does not store un-encrypted data on disk, ever.

On UWP, we store the data encrypted with DPAPI https://docs.microsoft.com/en-us/dotnet/standard/security/how-to-use-data-protection.

On .NET Fwk, .NET Core, .NET 5, we don't store the token cache at all, because storing it in a file is not appropriate for web site scenarios. Users need to provide their own token cache storage implementation. For PublicCLientApps (e.g. desktop), we suggest you use this cross-plat cache persistence strategy: https://github.com/AzureAD/microsoft-authentication-extensions-for-dotnet, which stores the data as follows:

• Windows - DPAPI
• Mac - KeyChain
• Linux - KeyRing

Note that we used to store tokens in WinCredManager, however this has a bunch of limitations, especially when it comes to size of keys etc. Tokens are not passwords, they are fairly long (2-3k chars) and would break WinCredsManager.

AFAIK (and MSALs are reviewed by security folk periodically), there is no security difference between DPAPI and WinCredsManager .

[brphelps]

ACK on wincredmanager.

I think there's a pretty big exception to what you're saying above -- Headless linux (arguably more widely used than headed linux) seems to still fallback to a plaintext password in that cred manager. Is there a way we can disable that behavior or cause it to throw instead of just warn?

Thanks!

[jmprieur]

@bgavrilMS : isn't this more a question for the extension library?

[bgavrilMS]

@brphelps - MSAL on its own will not store tokens anywhere for .NET Fx and .NET Core runtimes. You have to customize storage. We offer a solution for this here: https://github.com/AzureAD/microsoft-authentication-extensions-for-dotnet/ which seems to satisfy your needs, including Linux fallback.