CODEWITHSUNDEEP
oauth-2.0
DJClayworth
DJClayworth

Reputation: 26856

Making client secret configurable

We have a number of apps that communicate with each other. One app goes to a customer, and it has to communicate with a central server to get certain information. We use OAuth2 authentication, and we already use username and password to authenticate access to the central server app.

We hardwire an OAuth2 clientid and a client secret into the customer app so that the server app knows it is an instance of the app talking to it. Recently we have been asked to make the client ID and client secret configurable by the customer, so that each customer will have different OAuth clientid and client secret. id and secret would be generated by the server and the customer would set the id and secret on their installation of the app.

  1. Is this normal practice
  2. Does it add any useful security value

References to reputable publications addressing this would be especially welcome.

EDIT: We are using Resource Owner Password Flow, where username and password, as well as clientId and secret, are stored (encrypted) in the client app. The customer who installs the app gets given a username/password/clientid/clientsecret supplied to them, and that combination is always used to connect from client app to server app, whichever end user is logged in to the client app. (The id/secret/username/password combination can be changed if it is compromised, but changing it is expected to be rare.) This effectively makes the installation of the client app the resource owner. (I didn't design this)

Upvotes: 1

Views: 484

Answers (2)

Hans Z.
Hans Z.

Reputation: 53908

it is not considered best practice to hard code secrets into an app, the encryption of those only shifts the problem to the encryption key; there is a specification that addresses your "dynamic client" use case, called OAuth 2.0 Dynamic Client Registration https://www.rfc-editor.org/rfc/rfc7591

Upvotes: 0

jhinghaus
jhinghaus

Reputation: 855

I am afraid to say that the way your system uses the Resource Owner Password Flow is not normal practice (Resource Owner Password Flow). When client ID, client secret, username and password are hard wired in the client app, you could as well use the Client Credentials Flow.

Adding a configurable part to the hard wired authentication, poses the challenge to supply this new part to the customer in a secure way. On the other hand it gives you the possibility to revoke the authentication of a single customer in case it got compromised. Doing this in making the client ID and secret configurable is not normal practice. If you change the client app, so that the username and password are configured by the customer you would get closer to the standard Resource Owner Password Flow. This flow is deprecated but could be ok in your case (when to use).

By doing this step the resource is no longer owned by the client, but by a group of customers and customers can be excluded from this group.

Another way would be to change to the Client Credentials Flow and make the client ID and secret configurable. This way the customers clients would appear as different clients. The effect is nearly the same.

Summed up you have two sets of credentials (client ID:secret and username:password). Today both identify the client. One way or the other you could add the ability to identify the customer.

Upvotes: 2

Related Questions