Authentication and authorisation play an essential role in a digital world where data security and privacy are priorities. Imagine a situation where a third-party application needs to access one or more of your online services, but you do not want to share your login credentials. How can you ensure data protection while allowing that application to access only the necessary information? This is where OAuth 2.0 comes in.

OAuth 2.0 is an authorisation protocol used by modern applications to secure data and resources. It provides a secure and reliable model for users to grant third-party applications access to their protected resources – such as photos, e-mails, or contacts – without sharing their login credentials.

 

Whether you are a Software Engineer in search of a reliable and secure authorisation protocol, or a user concerned about the privacy and security of your data, this article will provide a comprehensive overview of OAuth 2.0 and how it can be applied to the architecture of our solutions.

  

Authentication vs. Authorisation

Authentication is the process of verifying the identity of a user or entity attempting to access a system or resource. It is the initial step where credentials, such as login and password, are provided to prove one's identity. Authentication ensures that only legitimate users gain access to systems and data, preventing unauthorised access by malicious individuals.

 

On the other hand, authorisation is related to the privileges and permissions granted to an authenticated user. Once authenticated, the user goes through the authorisation process, which determines the actions and resources they are authorised to access. This involves defining levels of access, restrictions, and rights for a specific user. Authorisation ensures that users have access only to appropriate resources and restricts access to confidential information or functionalities that are not relevant to their roles.

 

What is OAuth 2.0?

OAuth 2.0 is an authorisation protocol that allows protected resources to be accessed by third parties without sharing login credentials. The protocol involves different actors and authorisation flows.

 

It was developed by the IETF (Internet Engineering Task Force), an organisation responsible for developing Internet standards. The task force responsible for creating OAuth 2.0 (called the “OAuth Working Group”) was led by Aaron Parecki, Eran Hammer, Dick Hardt, and other security and authentication experts.

 

This protocol was based on its predecessor, OAuth 1.0. However, OAuth 1.0 had limitations and, based on previous experiences and the growing industry requirements, a new, simpler, and more flexible version was created, resulting in OAuth 2.0.

 

OAuth 2.0 Authorisation Flows

The OAuth 2.0 protocol defines several flows or grant types that can be used for authentication and authorisation between a client, an authorisation server, and a resource server. Each flow is designed to meet different use case scenarios, depending on the security needs and application requirements.

 

The most common flows in OAuth 2.0 are the “Authorization Code Flow”, “Implicit Flow”, “Resource Owner Password Credentials Flow”, “Client Credentials Flow”, and “Refresh Token Flow”.

  • Authorization Code Flow: This is the most common flow used in web applications. It involves exchanging an authorisation code for an access token. The user is redirected to the authentication provider, where they log in and grant permission for the application to access their resources. The application then exchanges the authorisation code for an access token that can be used to make calls on behalf of the user;
  • Implicit Flow: Similar to the Authorization Code Flow, but more suitable for Single-Page Applications (SPAs) where the client cannot securely store the token. In this flow, the access token is returned directly in the initial redirect after the successful user authentication;
  • Resource Owner Password Credentials Flow: In this flow, the user's credentials are sent directly to the authentication server to obtain an access token. This flow is more suitable for trusted applications, such as command-line applications or user-owned devices;
  • Client Credentials Flow: The client application authenticates directly with the resource server using its own credentials, the client ID, and the client secret. There is no user involvement in this flow, as the application is obtaining access on its own behalf, not on behalf of a specific user. This flow is commonly used in server-to-server integrations;
  • Device Authorization Flow: This flow is suitable for devices with limited resources, such as smart TVs or IoT devices. In this flow, the device displays a code for the user to authenticate on another device and provide the necessary authorisation. The device can then exchange the code for an access token.

 

OAuth 2.0 with microservices

In a microservices architecture, the most commonly used flow is the Client Credentials Flow, as it is used when a client application wants to authenticate directly with the authorisation server without involving a specific user.

 

Here is a detailed explanation of how the Client Credentials flow works:

  1. Client registration: Before the flow actually starts, the client application needs to be registered with the authorisation server so that there can be a client ID and client secret associated with it, which will be used for authentication with the authorisation server;
  2. Access token request: The client application requests the access token from the authorisation server. It provides the client ID, client secret, and the desired access scope. The request also includes the grant type defined as “client_credentials” to indicate the use of the Client Credentials flow;
  3. Client authentication: The authorisation server verifies whether the client ID and client secret match the records of the client application;
  4. Access token issuance: If the client application's credentials are successfully authenticated, the authorisation server generates an access token. This token serves as proof that the client application has been authenticated and has permission to access the requested protected resources;
  5. Access to protected resources: The client application includes the access token in each request, typically in the Authorization header in the format “Bearer <token>”. The resource server verifies the validity and authenticity of the token before granting access to the resources;
  6. Access token renewal: The access token issued in the Client Credentials flow has a limited lifetime. To obtain a new access token after its expiration, the client needs to repeat the flow by sending its credentials again and requesting a new access token.

 

Conclusion

In this article, we have explored the powerful OAuth 2.0 authorisation protocol and its importance in securely authenticating applications and services. We have understood the difference between authentication and authorisation, presented the different OAuth 2.0 flows, and provided a detailed explanation of the Client Credentials Flow. By understanding these concepts, developers can integrate systems and platforms securely, enabling collaboration between applications.

 

It is essential to follow implementation best practices and consider potential threats. However, with knowledge of OAuth 2.0, we are prepared to create more secure and integrated technological solutions, driving software development in a trusted environment.
Share this article