Simple as that!
Clients that can't maintain the secrecy of the client_secret in OAuth2 don't have to use it.
So what's the point of having it at all, if it's not necessary? What am I missing here?
Add a comment
|
2 Answers
There are a number of different grant types supported by OAuth 2.0, and they enable the client application to interact with a resource server on behalf of the resource owner in different ways.
There are security implications to using an implicit grant, which is the type that does not require a client secret. Specifically, in this authorization flow, the client (since there is no client secret) is entirely reliant on the resource owner (the user with the browser, generally) to obtain, present, and retain the access token. This significantly raises the bar required for protecting the token (you really can't have an application relying on this grant type that isn't completely protected by TLS/HTTPS) and there's additional risk of the token being stolen and misused without the client application's knowledge. Because of these additional risks, the RFC specifically recommends that you not rely on implicit grants unless you have to.
If your application does have the ability to properly protect a client secret, it is recommended to use the authorization code grant type instead. This allows the authorization flow to be managed via the application, and removes the requirement for the resource owner to handle the authorization process externally, and opaquely to the client. This means that the client can protect the access tokens as well, and does not need to rely on the users to keep them safe.
So, the client secret is not an extraneous option. It is an integral part of the preferred option. The implict grant type that does not require a client secret is simply a last resort of sorts for client applications that do not have the ability to implement a better option.
I haven't read the spec so I'm making assumptions here but it could allow you to support basic clients and differentiate depending on whether the client sends you a client_secret or not. For example, you could enforce a more stringent expiry rule on the request_token you send back to the client if they don't send you a client_secret.
Private secrets like the OAuth client_secret only work if you can trust the other party in the chain to maintain the secrecy of that information. So this rule means that if the client is unable to maintain secrecy, it should make it clear to the server by not providing the client_secret. The consequence of that rule is that if a client sends you a client_secret, it means it must be able to guarantee secrecy and you can trust it to do so. From the server perspective, it means you know whether the client can maintain secrecy and therefore adapt security policy accordingly. You don't have to do so but you can.
