top of page

OAuth 2.0 | Client Authentication

We started with learning OAuth as a standard for authorisation but now we've reached till a point in our OAuth journey that we're talking about Authentication in OAuth. What's going on?


If you've read last article (https://www.techlearnings.org/single-post/oauth-2-0-client-id-and-secret) about client id and secret, then this one will be easy to understand.


Let me re-iterate, we know the authorisation server must recognise the client in order to grant access token to it. How will it recognise? This process of recognising is called client authentication.



There are numerous ways in which a client can authenticate with authorisation server. It may also choose an authentication method at the time of registration with server. If no method is chosen, then default is client_secret_basic. Different ways are explained below -


  • client_secret_post: The client application sends its credentials in a POST request body for the token from authorisation server. The server validates credentials and if all found valid, returns the token.


  • client_secret_basic: The client application sends client id and secret in this method as well. But the way they are sent is different. (It is called HTTP Basic Authentication scheme)

2.1 Create a String: Client ID separated by colon and then followed by secret. (clientId:secret)

2.2 Base64 Encoding: The string created in last step is encoded using Base64 encoding.

2.3 Authorization Header: The encoded string is passed as value of Authorization header as -

Basic <encoded string>


  • client_secret_jwt: More about JWT is coming soon in future articles. For now, please understand, JWT stands for JSON Web Token, and client sends client id along with some more information which authorisation server understands, validates and successfully authenticates client if all found valid. In this way, client secret is not directly exposed in the request.


  • tls_client_auth: The server uses client certificate and client id received in the request for authenticating the client. In this way as well, secret is not exposed. If the certificate is a self signed one, it's called self_signed_tls_client_auth.


Let's sign off today with some of the best practices that we should follow in order to maintain the client id and secret secured -

  • We should not store them unencrypted in Git repository. We should keep them added in .gitignore file, so that so we don't commit and expose them accidentally.

  • Public clients which can be decompiled should not contain the secrets.

  • Config properties, log files, or error messages should not contain them. Not to mention, hardcoding them in code is worst.

  • As client secret needs to be passed to authorisation server, that API call must not be publicly exposed.

  • The API calls should be sent securely over network using protocols such as HTTPS.

  • We should prefer using short lived secrets so that they keep rotating.

  • Lastly, there are few code security tools like GitGuardian which one can use to scan the repositories for any leakage of sensitive credentials. We can leverage them to always remain on safer side.

Still curious! Where should we store them then? Let's spend few seconds understanding that as well.


I hope from above, it's clear for better security, these credentials need to sit somewhere outside the main application.

  • One way could be environment variables.

  • Another way could be on a separate server altogether which has proper security checks in place.

  • We can also leverage API secret management solutions such as AWS Secrets Manager.


Next, we would talk about another very important concept JWT. Till then stay tuned, stay connected!


Happy Tech Learnings!


Mentioning other OAuth articles already published as a handy reference -










.








Tags:

Коментарі

​
bottom of page