Allow writing to user-secrets from code

[hansmbakker]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

I am building a client to an external API which is protected by OAuth2 (using access_tokens and refresh_tokens).
In order to prevent logging in every time, I need to store the obtained access_token and refresh_token somewhere in between runs.

dotnet user-secrets works well for reading development secrets, but it is not well suited to invoke from C# (for the usecase of saving a token upon login, or for the usecase of saving new tokens after using the refresh_token: there is no Nuget package for it, so you would need to make a Process.Run call.

Describe the solution you'd like

I would like the core of dotnet user-secrets to be packaged as nuget package, so that I could update secrets from my code easily without having to write a wrapper around the CLI tool.

Alternative which I would not like is writing a wrapper around Process.Run.
Another alternative is doing a File.WriteAllText() / File.ReadAllText() on serialized OAuth2-tokens myself.

I also found the work in progress on dotnet user-jwts / #41956, but I believe that tool has a different purpose.

Additional context

I am building an Uno Platform project so I am looking for something that is cross platform.

[hansmbakker]

I guess I actually look for something like https://github.com/dotnet/maui/tree/main/src/Essentials/src/SecureStorage. This package is meant to read and write secrets in client code (also for non-development purposes) and it is a layer over the various platform-specific implementations.

However I am looking for something that is less linked to MAUI. The package's target platforms do not match my target platforms and including this package pulls in a lot of other MAUI dependencies.

Another option I found was https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/introduction?view=aspnetcore-6.0 but that is hard linked to ASP.Net Core..

[blowdart]

dotnet user-secrets is not meant as something to write to in code, or indeed for use in a production environment. Ever.

The problem here is that there are no real cross platform solutions.

What works on a mobile phone does not work in the cloud. What works on Windows does not work on Linux.

This is why Maui implements their own, for server applications in azure we recommend keyvault and their library, for AWS you'd use their facilities etc. ASP.NET's dataprotection doesn't even cover storage at all, it's a library to encrypt and sign payloads after which you do what you will with them.

To even have an abstraction we'd have to attest to the storage backing it, to ensure its suitable, not something that is easy, and certainly not something that ASP.NET would do, it would fall to the CLR, or we just let the underlying OS handle it and hope it gets it right, assuming the OS has that facility at all.

[davidfowl]

Are you sure you want to use user secrets for this? Feels like it would be better to pose this question on the maui repo to see what the current options are.

[hansmbakker]

Yes, probably you're right, and thank you for your feedback (both of you).

I posted it here since the user-secrets tool is part of this repo (which was a bit odd to me - I would expect it in a more generic project since it can also be used for console or desktop apps) and since the user-secrets tool also looked like semi-cross-platform (at least Windows, Mac and Linux are supported).

I do see it is not meant for non-development purposes.

As for the DataProtection APIs I thought it did give some pointers at https://docs.microsoft.com/en-us/aspnet/core/security/data-protection/implementation/key-storage-providers?view=aspnetcore-6.0&tabs=visual-studio?

I'll post an issue in the MAUI repo but I guess a more pragmatic idea is to just take the source of the SecureStore classes and put it in my own project and add the missing implementations for WinUI3 and Linux.

[hansmbakker]

Moved to dotnet/maui#9276.