1

The entire explanation of the client ID from RFC 6749:

The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.

The client identifier string size is left undefined by this specification. The client should avoid making assumptions about the identifier size. The authorization server SHOULD document the size of any identifier it issues.

From this we can conclude:

  1. It is not secret.
  2. It "represent[s] the registration information provided by the client", which sounds like there should be one per "client". And because of the mention of the "registration information", "client" presumably means "user" as opposed to "application", since applications typically don't have "registration information".
  3. It is "unique to the authorization server", which either means each authorization server (if multiple) is assigned one and only one (which would conflict with the previous point except in the case of having one client per authorization server, which we can safely ignore) or that each client is assigned a unique one per authorization server.

There is no mention what the client ID would be useful for. One suggestion by a fellow developer was that it could be used to differentiate between mobile apps and web users, but why would that be relevant to the authentication process? Either the client ID is used to determine how to treat the credentials, in which case it's trivially circumvented by setting another client ID in the request, or it's not, in which case it's not useful. I could kind of understand if it was used to differentiate which service the user was trying to authenticate against, but surely that's better done with a separate endpoint?

So what is the OAuth2 client ID actually or potentially useful for?


Context: I'm working on a web API with a simple authentication flow — no third parties involved. It looks like Django OAuth Toolkit only supports one client ID per application, and I'm trying to migrate to a non-guessable value. This unfortunately means I have to update all the clients at the same time as applying the new ID without what looks like significant rework of the application.

1 Answer 1

3

Suppose you are creating an application that accepts logins with either a Facebook account or a Google account. Both of those logins can be done with OAuth2.

As part of the OAuth process, both Facebook and Google need to have an URL to send the user back to your application after the authentication completed. This means that authorization servers need some kind of registration of the client applications that can use their services and the Client ID is used to identify which application the login attempt of the user relates to.

It "represent[s] the registration information provided by the client", which sounds like there should be one per "client". And because of the mention of the "registration information", "client" presumably means "user" as opposed to "application", since applications typically don't have "registration information".

Applications do have registration information (see also section 2 of RFC6749) and the term "client" does refer to an application.

It is "unique to the authorization server", which either means each authorization server (if multiple) is assigned one and only one (which would conflict with the previous point except in the case of having one client per authorization server, which we can safely ignore) or that each client is assigned a unique one per authorization server.

This means that Facebook and Google will issue different Client IDs even when the same application is registered with both providers.

1
  • Ah, it's for non-trivial authentication flows. That makes sense. I've added a bit of context to explain why it seemed redundant.
    – l0b0
    Dec 19, 2019 at 19:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.