locked
Where store ClientId and Secret RRS feed

  • Question

  • Hi

    I have an IdentityServer for create token for Oauth calls to api ws. In this project, i have to store the ClientId and SecretId.

    Now i have use two const (or appsettings.json file), but i think is not good for security reasons, because with a ILSpy softwares, is possible to read these two values. Where is better to store these Id? Using DataBase or something else, or do you generally use constants?

    Thanks

    Wednesday, April 17, 2019 3:15 PM

Answers

  • Storing values in a config/json is pretty common. It is only a security issue if the user has access to these files. For a web app this isn't an issue. For a desktop app then yes they will have access to that information. It actually doesn't matter where you store it because anybody can load up a debugger and view the contents of the values irrelevant of where you store them at. All they need to do is set a breakpoint on the line of code where you pass your client ID/secret to the API and they can see the value. It doesn't matter at all where those values came from. The moment your app drops them into a string they become visible. SecureString, which was designed to work around this, doesn't generally help out here.

    One way to work around that is to have an intermediate service that your app calls that then forwards the call on using the client ID/secret that is stored in the intermediate service. But this is probably overkill for many situations.

    Perhaps a better approach is to not rely solely on client id/secret. Client id/secret is designed for program to program communications. Adding an additional set of security constraints such as a client cert, IP filtering, etc. can add additional security to the mix. However if this is a generally reusable app then that becomes a lot harder. Alternatively maybe ever app user gets their own credentials. This is what PATs are for. It would seem to fit better if you want apps on clients to be able to communicate with an API.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Pengo11 Thursday, April 18, 2019 7:33 AM
    • Unmarked as answer by Pengo11 Thursday, April 18, 2019 7:47 AM
    • Marked as answer by Pengo11 Thursday, April 18, 2019 7:48 AM
    Wednesday, April 17, 2019 5:59 PM

All replies

  • From the security perspective:

    It must be a configurable value, thus apsettings.json or a database are equally good for that. The key is the access to those files (NTFS permissions, database access).

    When a higher level of security is needed, then you need to encrypt those values against the user/machine key ring. But the security gain is lesser than many people might think.

    Imho for such credentials it is sufficient to keep them in the settings file. Cause it is only readable by the admin and the service account where you run your software with.

    Wednesday, April 17, 2019 3:30 PM
  • Storing values in a config/json is pretty common. It is only a security issue if the user has access to these files. For a web app this isn't an issue. For a desktop app then yes they will have access to that information. It actually doesn't matter where you store it because anybody can load up a debugger and view the contents of the values irrelevant of where you store them at. All they need to do is set a breakpoint on the line of code where you pass your client ID/secret to the API and they can see the value. It doesn't matter at all where those values came from. The moment your app drops them into a string they become visible. SecureString, which was designed to work around this, doesn't generally help out here.

    One way to work around that is to have an intermediate service that your app calls that then forwards the call on using the client ID/secret that is stored in the intermediate service. But this is probably overkill for many situations.

    Perhaps a better approach is to not rely solely on client id/secret. Client id/secret is designed for program to program communications. Adding an additional set of security constraints such as a client cert, IP filtering, etc. can add additional security to the mix. However if this is a generally reusable app then that becomes a lot harder. Alternatively maybe ever app user gets their own credentials. This is what PATs are for. It would seem to fit better if you want apps on clients to be able to communicate with an API.


    Michael Taylor http://www.michaeltaylorp3.net

    • Marked as answer by Pengo11 Thursday, April 18, 2019 7:33 AM
    • Unmarked as answer by Pengo11 Thursday, April 18, 2019 7:47 AM
    • Marked as answer by Pengo11 Thursday, April 18, 2019 7:48 AM
    Wednesday, April 17, 2019 5:59 PM