Security of OAuth Authorization Code with Semi-Private Secret

Question

I'm working on an application in which the OAuth secret won't be able to be secured completely; there is a group of users to whom it will be exposed by necessity. So imagine a situation like the following:

A company is developing software that it hosts for the public that relies on OAuth2 to some 3rd party for authentication. But unavoidably the OAuth secret for this application will be exposed to all employes of the company. Presumably, some bad employee could use it for nefarious purposes or share it with someone else who would.

I was initially inclined to think that such an environment should use the implicit OAuth2 workflow which isn't predicated on a secret key remaining a secret on the server. However, the more I read about it, the more inclined I am to believe that the authorization code workflow might actually be a better fit here, because the secret key -- while not perfectly kept secret -- is at least only exposed to a subset of "trusted" actors.

Am I correct in believing that the authorization code workflow would only increase security in an environment in which the key cannot be kept entirely secret? Are there any threats introduced by using the authorization code over the implicit workflow if the secret has been compromised? If anonymous/public users would not have access to the key, is there any reason other than convenience/simplicity to use the implicit workflow over authorization code?

Answer 1

Authorization code grant is more secure than implicit even in case the client secret can leak. Such scenario is the same as using authorization code grant with a public, instead of a confidential, client.

The only benefit of the implicit grant is simplicity and performance improvement (avoiding a back-channel call between client and authorization server).

Implicit grant has at least these weaknesses which are not present in the authorization grant:

• the access token is transmitted in URI fragment which can expose it to unauthorized parties (e.g. in browser cache, referrer parameters, logs)
• in implicit grant resource owner has access to the access token

In case the secret gets leaked in authorization grant, a potential attacker will be able to:

• request tokens on behalf of the client (and potentially impersonate the client e.g. by DNS manipulation), but the same applies to the implicit grant
• in case attacker would be able to obtain refresh tokens (by compromising the client) he would be able to re-use them (which can be mitigated by not storing refresh tokens)

In any case you should make sure that the authorization server registers URL of your client and validates that the redirect_uri provided during authorization code flow is valid for the client. You have to use SSL/TLS for transfer of the authorization code to the client and exchange of the authorization code for the access token.

You can find more discussion on this subject in the OAuth 2.0 threat model document (https://www.rfc-editor.org/rfc/rfc6819)