Token-based Authentication is one of the most popular and widely used authentication and identity management systems used across the world. It is simple, easy to integrate, and makes the user experience better.
Imagine you are reading your favorite article in Medium, and you wish to save it to your account. Let’s say you have not yet logged into Medium, so you will navigate to the login page. You will find that you will have many options to login with - Google, Facebook etc.
You thought you would use your existing Google credentials to login to Medium, so you will click on the “Sign In with Google” button. You will be redirected to Google, where you will enter your Google credentials. You will be redirected back to Medium where you can see you are now logged into Medium.
When you click on the “Sign In with Google” button, Medium constructs a Google Sign-in request URL with some parameters and values specific to it and redirects to that URL within Google.
Google validates those parameters and, after you have given your Google credentials, redirects back to Medium with an authorization token/code as requested by Medium. This token/code has an expiry time attached to it.
Medium can then use this token/code to query your identity information available in Google for a limited amount of time until the token/code is valid. After a period of time, the code/token expires and is no longer valid. Medium has to then request another token/code, or prompt you to log in again.
This is how a typical Token based Authentication system works. You will only enter credentials at a centralized Identity Provider site, and the application accesses your profile or identity using a token that this Identity Provider issues to this application.
This token is application specific, and one application cannot use this token from another application. This way, you can ensure that your information is not being misused.
Advantages of a Token-based Authentication Mechanism
The following are 5 advantages of a Token-based Authentication system from an application developer perspective -
- Tokens are stateless, which eliminates the need to maintain user session information on the server side
- Since there is no session attached to a request, tokens are best suited for distributed environments and support scaling.
- Tokens have very short lifespans. Hence they can help reduce unauthorized access or request hijacking.
- Tokens can be generated with attributes to access only specific resources or specific roles/scopes. This enables fine-grained access control in cross-domain authorization.
- Since there is no concept of cookies, token-based authentication works best in mobile applications where each request is stateless, and mobile apps don’t need to worry about cookies/sessions.
However, there are a few limitations to Token based authentication, which one must also consider.
Limitations of a Token-based Authentication Mechanism
- Since tokens have a short lifespan, applications need to be designed to continuously request for fresh tokens or users may need to re-authenticate once the token expires.
- Applications need to support additional mechanisms for token issuance, storage, and revocation, which can add complexity to the authentication process.
- Applications need to store tokens securely on the client side, potentially raising security concerns if not managed properly.
- Since a Token impersonates a user state, applications must use these tokens securely to prevent interception or tampering, which could be a challenge if proper security measures are not in place.
- If a token is compromised, it can potentially grant unauthorized access until it expires or is revoked, making it a single point of failure for authentication security.
Types of Token-based Authentication Protocols
Based on the requirement and nature of security, the following are the different types of token-based authentication protocols widely used in applications.
- OAuth (Open Authorization): A delegation protocol allowing third-party applications to access user resources on their behalf.
- SAML (Security Assertion Markup Language): XML-based token format commonly used for single sign-on (SSO) in enterprise systems.
- OIDC (OpenID Connect): An identity layer on top of OAuth, providing user authentication and profile information.
- Kerberos: Network authentication protocol primarily used in Windows environments for secure single sign-on (SSO) capabilities.
Among these, OAuth and OpenID are the two popular token-based authentication mechanisms used in web applications for delegating third-party authentication and authorization.
Different Types of Tokens
Within the context of OpenId and OAuth, there are 3 different types of tokens that are issued by the Identity Providers, which you need to know about.
The following are the different types of Tokens -
- ID Token - Primarily used in OpenID connect flows, an ID Token provides identity information about the authenticated user. It contains user-specific claims (e.g., user ID, name, email) as a JSON Web Token (JWT).
- Access Token: Access Token grants access to protected resources or APIs on behalf of a user or an application. It contains scopes and permissions granted to the application. It is a short-lived token and requires renewal using a refresh token.
- Refresh Token: A Refresh token is a long-lived token that the application can use to request for access token from the identity provider without having to request for user re-authentication.
ID Token identifies the user, Access Token provides access to protected resources, and the Refresh Token lets the application request new access tokens when the original one expires.
Who issues Tokens?
A secure token server, also known as an "Authorization Server" or "Token Issuer," is a critical component in token-based authentication systems. Its primary function is to issue and manage tokens for client applications and users. These tokens are used to verify the identity of users and grant access to specific resources or services.
The secure token server plays a crucial role in ensuring the security of the authentication process by:
- Token request authentication
- Issuing and Validating Tokens
- Revocation and setting Token Expiry
- Scope and Permissions
- Ensuring Secure Communication
What is an Authentication Flow?
In order to obtain tokens from an authorization server, an application must follow certain steps, which can also involve user input. These series of steps are together called an authentication flow.
At the end of an authentication flow, an authorization server issues tokens to the third-party application, also known as a client, on behalf of the user that has been authenticated with the server. The tokens are issued as requested by the client, with the scopes that are defined in the authorization server.
Different Types of Authorization Grant Types
There are different Authorization Grant Types that are defined in the OpenID and OAuth protocols. These define the ways in which clients can request tokens from an Authorization Server.
These are supported by most Identity Providers and Authorization Servers such as Identity Server 4, AWS Cognito, Azure AD B2C, etc. They are -
Implicit: Used to retrieve tokens via browser. The client redirects the user to the authorization server, where after the consent, the Server redirects back with the token without any backend call. This is not recommended. Authorization Code flow must be used instead.
Authorization Code: Used to retrieve tokens in the back channel instead of front-end via browser, now recommended for all client-side applications. The client redirects the user to the Authorization Server; the user is authenticated and provides consent. The Authorization server redirects back to the client with an authorization code, followed by an API call to get the required token information.
Client Credentials: Used in App-to-App request scenarios, where an Application requests Tokens from an Authorization Server with its ClientId and Client Secret. The Authorization Server returns back with Tokens. No consent or redirection is present, and requests happen via backend API calls.
Resource Owner Password Credentials: Used in cases where an application impersonates a user and requests tokens based on a username-password combination.
Hybrid: Hybrid is an authentication flow where we combine two or more authentication flows to get multiple token results. possible examples are - an authorization code with an access token, an authorization code with an id token, an access token, an id token, etc.
Refresh Token: This is used when clients need to request a new access token using a refresh token, which was obtained during the initial authentication.
Conclusion
Token-based Authentication is core to modern-day application authentication and user identity management. Applications can offload their Authentication and User Identity Management to Authorization Server components which can handle the user authentication and issue tokens that have shorter lifespans and limited information. With this mechanism, applications don’t need to worry about issues such as Session State, Scalability, Security, etc. Applications can also impose resource-based authorization based on the scopes that these tokens contain.
Protocols such as OAuth, OpenID, SAML, and Kerberos provide us with various mechanisms and guidelines on how to request tokens and what type of tokens are returned. Applications can implement any of the above-mentioned Authentication Flows, such as Implicit, Authorization Code, Client Credentials, or Hybrid, to request for tokens based on the scenarios.