1
votes

With regards to OAuth 2.0, my previous understanding is that client_secret should be used for authorization_code grant, which is supposed to be "more secure" (client_secret was required for some tutorial out here 1 2)

However I saw a library when using authorization_code, didn't brother to check client_secret if not provided. Which makes me wonder the usage of client_secret and dig deeper into the spec of OAuth2.

I then looked into the RFC for OAuth 2 (https://tools.ietf.org/html/rfc6749#section-4.1), and found that client_secret is not required at all for authorization_code grant flow.

If you scroll down to the required param for authorization_code flow https://tools.ietf.org/html/rfc6749#section-4.1.1, you will see that client_secret is not even mentioned

So my question is:

  • Is client_secret required for authorization_code grant type?
  • If it is suggested to have client_secret instead of required, will there be any official documentation that tell us that client_secret is suggested?

Thanks!

1

1 Answers

1
votes

Good question and one of the things I find most annoying about OAuth2.0 - understanding the security protocol around public clients.

To answer your questions as best I can:-

Is client_secret required for authorization_code grant type?

No. If the client is a public client then it should be allowed to use this grant type without authenticating itself (providing it registers a redirection endpoint). The problem is that there seem to be several implementations of OAuth2.0 Servers that don't allow public clients for this grant type.

If it is suggested to have client_secret instead of required, will there be any official documentation that tell us that client_secret is suggested?

You probably need to look at the documentation of the actual OAuth2.0 provider you use, rather than the generic IETF specification as they may specify rules around public clients outside of the RFC.

The 6749 RFC pretty much just says that the the Auth Server SHOULD deal with the fact public clients are more insecure, without giving the exact details of how to.

e.g. Section 10.1 says:

 The authorization server must consider the security implications of
   interacting with unauthenticated clients and take measures to limit
   the potential exposure of other credentials (e.g., refresh tokens)
   issued to such clients.