1
votes

An API consumer, subscribes to an API on a particular API Portal. He receives client ID and clinet secret. There is a specific quata set for the subscription.

[Happy day scenario]

  • He then decides to create a web app and places the client secret securely on the server.
  • He then decides to go with Auth code grant
  • Subsequect calls to get an acces_token after receiving the users auth_code will be server-to-server request with the client secret.
  • And thus the purpose is solved with the client_secret stored and used securely.

[Not a happy day scenario]

  • Later, he decides to create a native app (public client - Android/IOS app) which uses the same API which he previously subscribed.
  • For the native app to access the API's, it requires access_token.
  • The user authenticates against the identity server and provides grant.
  • Receives an auth_code and redirected back to the app.
  • The App then will require this auth_code + client ID + client_secret to get the access_token.
  • But in this case the client_secret is not stored securely. The app can be decompiled and the client_secret can be misused at the cost of the API consumer purchasing/subscribing to the API.

Implicit flow option is ruled out.

Possible workaround:

  • Create a proxy where the client_ID and client_secret are stored and the native app calls this proxy with auth_code to gain a access token.
  • Encrypt the client_secret Advise required on better and recommended solution/model please.
1

1 Answers

0
votes

I found a better way to address this by creating an API for the /oauth2/authorize endpoint available locally.

So here is the flow:

  1. My API will accept username, password and clientID in request
  2. API will verify the received clientID against the DB
  3. If valid, fetch the client_secret for the clientID from DB
  4. Create the Authorization: Basic base64(clientID:client_secret) on the runtime - using scripting fiter
  5. Add this created Authorization header to the request
  6. forward this request locally to the actual /oauth2/authorize endpoint

This works perfect by not embedding the client_secret in the public client (native apps) and fits my case as I manager the API gateway :)

Note: works for auth_code grant flow as well