CODEWITHSUNDEEP
oauth-2.0spring-security-oauth2
user3529850
user3529850

Reputation: 976

OAuth storing client id and secret in database

I was reading an article about OAuth 2.0 with jwt tokens. Interesting part is when author describes client_secret, he says:

In a non-trivial implementation client ids and passwords will be securely stored in a database and retrievable through a separate API that clients applications access during deployment.

Now let's say I have a frontend app in angular and a backend app in spring with MySQL db.

My question is what author meant by the aforementioned quote. Is it, that client (frontend app in this case) makes a call using client_id and secret (nothing changes here), but backend is checking provided "credentials" not by comparing with values stored in plain-text (in application.properties in that case), but making a hash from received values and comparing with hashed version in db ?

EDITED: Example of use case

  1. User john doe opens log in page. Provides credentials: username:john.doe and password:john1. Clicks sign in.
  2. Angular-frontend intercepts request, and executes a method (f.e. obtainTokenForUser()) in order to get a short-period-valid jwt token for the user. For that reason angular-app sends an OAuth2.0-compliant request to the authorization server. Before sending contant AWS KMS to get its client_id and secret in order to attach to the request. In the end, the request from angular to auth server looks like: curl front-app-sp3:frnt4pP@<auth_server_ip_addr>:<auth_server_port>/oauth/token -d grant_type=password -d username=john.doe -d password=john1
  3. Authorization server contacts AWS KMS for received client_id:front-app-sp3 and client_secret:frnt4pP. It finds the entry, passwords matches, validation correct. Auth server generates a JWT token valid f.e. 5 minutes. The token is signed by the server using AS_pr1v4t3 private key. Authorization server returns a token to angular app.
  4. User is logged in. User requests a resource in the main app (in spring), thus angular adds an obtained token and sends the request to the "Main-web application".
  5. Resource server in the "Main-web application" validates token. Token is correct and valid. Resource is returned.

Upvotes: 4

Views: 9141

Answers (1)

Mavi Domates
Mavi Domates

Reputation: 4521

I don't think that's what the author is referring to. He is talking about instead of having client_id and client_secret in your application.properties they are to be stored in a DB which your backend can access through a different API. I would argue that the client_id belongs more to the application.properties than the secret management service though. Your front-end (angular app in this case) should never have access to client-id or the secret. Your server which the angular app is connected to (through some REST services I imagine) should never have direct access to the secrets either, it should go through a separate secret management API. It's ok for your server to have the client_id in the application properties, but the secret should be stored in a very secure place.

This is an already implemented pattern though. Instead of having the secret values directly in the app.config / application.properties file you should have them in something like:

These would allow you to store / update / retrieve and rotate your secrets.

Upvotes: 2

Related Questions