Hash OAuthClient secrets

[myssto]

Instead of client secrets being stored in the database as plaintext, they are now hashed and validated using Identity Framework's IPasswordHasher<T>. This pull includes some light refactoring of the OAuthHandler, as I feel delegating the creation and updating of clients to the client service and repository is more proper.

Now that we do not have access to the plaintext client secrets, the secret for a client will only ever be returned once when a client is created. If a user loses access to the secret, they will have to reset it.

/me should have client access and manipulation endpoints, but I will implement that in a new pull. I don't believe web has implemented features regarding clients at all, so this should be safe to push through.

Deployment Note: oauth_clients table needs to be truncated. All existing clients should be re-created (or secrets reset) as they will no longer be able to be authorized after this pull.

New Endpoints

• POST /users/{id}/clients/{clientId}/secret:reset
  • Generates a new secret for an existing client
  • Returns a new OAuthClientCreatedDTO
  • Example (Reset client secret of user 703, client 3)
  • Request

    fetch("otr.stagec.xyz/api/v1/users/703/clients/3/secret:reset",
     {
       method: "POST",
       headers: new Headers().append("Authorization", "Bearer {}")
     });

    • Result

      {
      "clientId": 3,
      "clientSecret": "asdasdasdasdasdasdasdasdasdasd",
      "scopes": [],
      "rateLimitOverrides": { "permitLimit": null, "window": null }
      }

Breaking Changes

Schema Changes

• OAuthClientDTO (Returns from GET /users/clients, etc)
  • Removed clientSecret

  • {
     "clientId": 3,
     "scopes": [],
     "rateLimitOverrides": { "permitLimit": null, "window": null }
    }

• New OAuthClientCreatedDTO (Returns from POST /oauth/client, POST /users/{id}/clients/{clientId}/secret:reset)
  • Endpoints that return this DTO will be the only time the secret is viewable in plaintext (un-hashed)

  • {
     "clientId": 3,
     "clientSecret": "asdasdasdasdasdasdasdasdasdasd",
     "scopes": [],
     "rateLimitOverrides": { "permitLimit": null, "window": null }
    }

Closes #146

[hburn7]

I realize we can easily store an encryption key secret and be able to keep the same flow (e.g. user can view their secret as many times as they want). We can reference the secret and securely decrypt the secret before returning it.

I think this is a good way forward, what do you think?

[myssto]

I realize we can easily store an encryption key secret and be able to keep the same flow (e.g. user can view their secret as many times as they want). We can reference the secret and securely decrypt the secret before returning it.

I think this is a good way forward, what do you think?

Hard disagree... Encryption sucks, and hashing is the industry standard for password-like authentication. If we were to go the encryption route, we'd have to consider key rotation and a million other things. I'd give this SO answer and the linked material a read, it gives a good bit of insight into what I'm talking about. This is simple, secure, works with minimal effort, and realistically if a user has to reset their secret it would not be effecting much. Shouldn't be misplacing it in the first place :P

[hburn7]

Alright, that's fine then. We can stick to hashing.