1

Let's assume that a client has the client secret exposed somewhere. What are the risks that the client and its users are exposed to? Are those the same as having implemented the implicit flow from the begin with?

I would say that, the risk here is for an attacker stealing a code, and since the client secret is available, assuming no other form of client authentication is performed, then the attacker would be able to exchange the code to token. So it looks like it's similar with the risks of implicit flow, but a bit more secure since by default the tokens are not exposed in the user-agent (implicit flow could use for example response_mode=form_post and avoid that scenario)

1
  • If you are looking for additional mechanisms, that secure this grant, take a look at PKCE oauth.net/2/pkce.
    – BenjaminH
    Feb 3, 2021 at 14:18

2 Answers 2

1

One of the biggest risks I see is that whoever has the secret can now perform a client credential grant and then get an access token with whatever scopes that client has access to. Depending on the APIs, that could be a major compromise.

The other issue has to do with client impersonation. If a rogue app developer has your client id and secret, they can trick users of their app into granting them access to your APIs. There have to be a few other weaknesses for this to be pulled off successfully (for example, the AS would have to be lax in the validation of the redirect_uri). If this malicious app can get your users to use it, it would then be able to get an access token (using your exposed secret) for those users that is valid against your APIs. This is clearly a very bad thing.

0

Yes, exposing the client secret would increase the risk of a token being compromised, but there are other pieces that would need to perfectly fall into place for that to happen. If we look a an example POST for a token in the Authorization Code Grant Flow:

POST /oauth/token HTTP/1.1
Host: authorization-server.com

code=Yzk5ZDczMzRlNDEwY
&grant_type=code
&redirect_uri=https://example-app.com/cb
&client_id=mRkZGFjM
&client_secret=ZGVmMjMz

Implementation may differ in slight ways but let's look at a couple other pieces of information (in addition to the client_secret) that the attacker also needs to get a token:

code - The authorization code that is granted is typically single use only. Obtaining a code would mean having access to an authorized user's account and completing the authorization request prerequisite to this grant type.

client_id - While not a 'secret' per se, this is the registered applications id which would need to obtained and is not usually something that is guessable. (though I suppose if the attacker has the client secret, they also have the id? Seems odd to have obtained one and not the other)

The authorization code is definitely added security compared to implicit grant, but also like you suggested, Auth-code is much more secure because the token is not meant to be returned to the user-agent (browser). It's more commonly implemented in a backend/frontend application with the code/token exchange happening in the backend.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .