OpenID Connect: The Key to Seamless User Authentication
“Authentication is the key that unlocks the door to a secure digital world.” — Unknown
This is a continuation of my previous article OAuth 2.0 . I mentioned OAuth protocol is used for Authorization. There are some reasons why it should be used for Authentication.
- Lack of standardisation. There is no standard way to get user information.
- Scope definition can vary across different authorization servers. It can be difficult to get user information across various providers.
During the initial days OAuth became so popular that people started using OAuth to get user details and perform authentication. This misuse led to lack of standardisation and confusion. Inorder to resolve this, OpenId Connect was introduced as a small layer on top of OAuth. This layer is responsible for the authentication part, while OAuth takes care of authorisation part which it is supposed to do, as shown in the below diagram.
What OpenID adds on top of OAuth 2.0
- ID Token
- An endpoint for getting user information
- Standard set of scopes
- Standardized implementation
So with OpenID connect on top of OAuth, the client will need an ID token along with an Access token from the authorization server. Client will request “openid” in the scope while connecting to the Authorization server.
As compared to the OAuth workflow there is only a minor change with the OpenId connect workflow. Refer OAuth workflow for the complete steps.
ID Token
An ID token is a JSON web token (JWT) that contains information about the authenticated user. It is a secure and compact way to transmit user information between different systems. This token will contain information about the user, which the application can understand and perform its service. If the application needs more information about the user, it can use the access token to fetch a userinfo URL to get more details about the user.
It consists of 3 parts separated by a period “.” character.
- Header: The header of the ID token contains metadata about the token itself, such as its type (JWT) and the algorithm used to sign it. The header is base64-encoded and included at the beginning of the ID token.
- Payload: The payload of the ID token contains the actual user information, such as the user’s name, email address, and unique identifier. It also includes metadata about the token, such as the issuer, audience, and expiration time. The payload is also base64-encoded and included in the middle of the ID token.
- Signature: The signature of the ID token is used to ensure that the token has not been tampered with during transmission. It is generated by signing the header and payload with the Authorization server private key, using the algorithm specified in the header. This way the client can ensure the authenticity of the ID token. The signature is included at the end of the ID token, after a period (“.”) character.
Let’s go a little bit in detail about how the signature is verified by the Client. The client can verify the signature by performing the following steps:
- Decode the header and payload parts of the ID token from base64 encoding.
- Concatenate the decoded header and payload parts with a period (“.”) character between them to form a message.
- Retrieve the public key of the Authorization server, whose private key was used to sign the ID token.
- Use the algorithm specified in the header of the ID token to verify the signature. This involves using the public key to decrypt the signature and comparing the resulting hash to the hash of the concatenated header and payload obtained in step 2. If the two hashes match, the signature is valid and the ID token is authentic.
Conclusion
OpenID Connect provides a standard way to authenticate users and obtain basic profile information about them using an ID token. The ID token can be used in a wide range of applications, including web and mobile applications, and can be easily integrated with popular programming languages and frameworks.
Reference: Talk by Nate Barbettini about Oauth 2.0 in OktaDev YT channel
