OAuth 2.0 | Client ID and Secret

In continuation on our OAuth journey, let's talk about today, two very important concepts - clientId and secret. These two are very crucial from understanding point of view, and our knowledge is incomplete without knowing these two terms.

In fact the concept is generic enough, it's not actually just related to OAuth. It will be helpful if you go through last articles before reading further. (In the client credentials grant type, we talked slightly about client id and secret)

Client ID: It's a public identifier to uniquely identify a client application. Secondly, we would like it to be difficult enough not to be easily predictable and rememberable by anyone for security reasons. e.g. Sample client id from Google looks like this: 1234567890-abc123def456.apps.googleusercontent.com

Client Secret: It's also an identifier for the application but this MUST BE SECURED from any unauthorised access. Again, should be difficult enough not to be predictable and rememberable.

A simple analogy can be username and password. We can consider client id as username and client secret as password which we would never like to expose to anyone.

From above analogy, looks like client secret is always required, but actually it's optional. If we're developing a public application, we might not want a client secret. Hence, it's more preferable to have it for server side applications.

Next comes important part, where do client id and secret come into picture w.r.t OAuth?

If we see the above image from last article (https://www.techlearnings.org/single-post/oauth-2-0-scopes-roles-grant-types) , the client application has to interact with Authorisation server. How will Auth server recognise the client application?

Actually , the authorisation server already knows the client application. But how?

The client first registers with the authorisation server (associated with resource server), and at the time of this registration, client id and secret are generated by the server. e.g If we register our application with Google, then Google will provide a client id and secret to us post successful registration. If we register with Facebook, then it will generate a client id and secret for us. Of course, not to mention - Google and Facebook ids are going to be different.

Whenever the client application needs a resource from the resource server, it needs to first authenticate itself with the authorisation server using its client id and secret. Here is also a catch -

This authentication is required for confidential clients not for public clients. (Diff between them is already explained in last article (https://www.techlearnings.org/single-post/oauth-2-0-scopes-roles-grant-types).

As mentioned previously, OAuth is a vast concept, with still more to cover, stay tuned!

Do connect or follow me at LinkedIn, subscribe at YouTube/Facebook/Twitter!

Happy Tech Learnings!