3

The OAuth2 password grant_type states,

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.

Let's assume that I have both confidential and non-confidential clients. This seems like a very plausible assumption: I have some third-party developers, who run server side applications, and they are thus issued a client_id & client_secret pair; I also have a mobile application and a web application; obviously these can't keep the client_secret confidential, as they're published publicly.

So, in the case of a public client w/o a client secret, the above "If the client type is confidential" is false, and they don't authenticate with the authorization server as described by §3.2.1.

However, as a server,

The authorization server MUST:

  • require client authentication for confidential clients or for any client that was issued client credentials (or with other authentication requirements),

Okay, but given that the above text means that only confidential clients will send their credentials, how is this possible? If I don't see credentials on the request, how do I, as an authorization server, know that this is a public client, as opposed to a confidential client that has failed to supply authentication?

Note that in "OAuth2 Simplified", there is an example grant_type=password request that includes a client_id, but not a client_secret; does OAuth require that at least a client_id is always specified during grants? (And thus, the authorization server could identify the client, and thus, whether they need to fully authenticate.) Does the RFC state this anywhere?

Improve this question
1
  • Can't you have separate client_id's for confidential and non-confidential clients?
    – SilverlightFox
    Jun 9, 2016 at 10:54

1 Answer 1

Reset to default
2

According to section 2 - client registration a client is registered with the authorization server before initiating any of the flows.

Client registration includes specifying the client type (confidential or public), and is subsequently assigned a client ID. So when the authorization server receives a request for a given client ID, it knows whether it is confidential or public.

For authorization code and implicit grants, the client ID is a required field.

Use of password credentials grant is not recommended, and does not actually require client ID - I mean you're passing your actual credentials directly to the token endpoint, who cares about client ID or client secret!

Improve this answer
4
  • Ah, excellent point re the password credentials grant. I was looking primarily at that one (we use it way too much); I did not notice the others specify client_id as being required. I'm assuming the implication is that the client_id in the body MUST match the Authorization header, iff the client passes the secret in via that means? (is this stated anywhere?)
    – Thanatos
    Jun 27, 2016 at 19:50
  • Yes, passing it via Authorization header is recommended, and has to match the corresponding client_id. Spec also says you can pass them in the request body tools.ietf.org/html/rfc6749#section-2.3.1 but not recommended.
    – HTKLee
    Jun 28, 2016 at 0:17
  • My assumption (and yours) is that it must match. I actually don't see where §2.3.1 says that. While earlier, you had me convinced about password grants, I am now not convinced. I had forgotten that that section explicitly requires the client_id.
    – Thanatos
    Jun 28, 2016 at 0:54
  • client_id and client_secret must match by inference. Client registration requires you specify client_type and if it is confidential, you will need to specify something in order to establish confidentiality such as a client_secret; auth server then associates that registration with a unique client_id as per §2.2.
    – HTKLee
    Jun 28, 2016 at 1:38

You must log in to answer this question.

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