CODEWITHSUNDEEP
oauthoauth-2.0
machete
machete

Reputation: 1157

What are the limits of public clients in OAuth 2.0

OAuth 2.0 specifies two client types:

and section 2.2 says:

The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication.

While it is clear to me that public clients are primarily used for the implicit flow, there is more to this than it seems. When performing the auth code flow, we first request the authorization endpoint with our client_id, no secret required. Then, after getting the user's consent and the authorize code, we request the token endpoint. According to spec, we are able to request this endpoint without a client_secret:

client_id

     REQUIRED, if the client is not authenticating with the
     authorization server as described in Section 3.2.1.

If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

...

The authorization server MUST:

...

o ensure that the authorization code was issued to the authenticated
  confidential client, or if the client is public, ensure that the
  code was issued to "client_id" in the request,

So basically this section says that we are able to request this endpoint without a client secret. Now, it doesn't say anything about refresh tokens other than that those may be included in the request.

Refreshing an access token mentions:

Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the client to which it was issued. If the client type is confidential or the client was issued client credentials (or assigned other authentication requirements), the client MUST authenticate with the authorization server as described in Section 3.2.1.

So basically we're allowed to refresh the access token without client authentication.

Now, what confuses me is that the implicit flow does not allow issuing of refresh tokens:

The authorization server MUST NOT issue a refresh token.

It doesn't say explicitly why we can't do that, only that we're not allowed to. My reasoning is that this isn't allowed because the client can't be trusted. But since the authorize code flow is allowed for public clients, why do we actually need the implicit flow, if the same thing can be achieved with a public client, plus getting a refresh token?

I'd be very glad if someone could clarify this.

Upvotes: 2

Views: 2136

Answers (1)

geliba187
geliba187

Reputation: 397

You are allowed to request/refresh access token without client secret at your own risk. Or we can say it depends on your security requirements. The spec only clarifies client authentication for confidential clients, basically if the client is confidential. it MUST be authenticated by the server.

For public clients, the spec says:

The authorization server MUST NOT issue client passwords or other client credentials to native application or user-agent-based application clients for the purpose of client authentication.

So public clients can't even have a secret to be authenticated with. And then the spec also says:

When client authentication is not possible, the authorization server SHOULD employ other means to validate the client's identity -- for example, by requiring the registration of the client redirection URI or enlisting the resource owner to confirm identity. A valid redirection URI is not sufficient to verify the client's identity when asking for resource owner authorization but can be used to prevent delivering credentials to a counterfeit client after obtaining resource owner authorization.

Also you may look at PKCE.

Get back to your question, I think you are misunderstanding:

According to spec, we are able to request this endpoint without a client_secret.

Not quite right, you must authenticate confidential client and you can't authenticate public client using a client secret (it does not have one).

The authorization server MUST NOT issue a refresh token.

I think it is all matter of security. In implicit grant, we are operating under a presumably unsafe environment. Exposing refresh token could harm your system, since we already expose access token in this grant type (Please read security consideration for access token).

But since the authorize code flow is allowed for public clients, why do we actually need the implicit flow, if the same thing can be achieved with a public client, plus getting a refresh token?

They are meant for completely different use cases. From https://oauth.net/2/grant-types/implicit/

The Implicit grant type is a simplified flow that can be used by public clients, where the access token is returned immediately without an extra authorization code exchange step.

It is generally not recommended to use the implicit flow (and some servers prohibit this flow entirely). In the time since the spec was originally written, the industry best practice has changed to recommend that public clients should use the authorization code flow with the PKCE extension instead.

Lastly, I suggest you to play with this site to get a better understanding of different grant types.

Upvotes: 2

Related Questions