Security: a Brief Review of Claims-Based Authentication

1. Introduction

When a user accesses an application, the identity provider authenticates the user and issues a token. Based on the application’s trust in the identity provider, it grants or denies access.

In this tutorial, we’ll discuss how claims, tokens, and the authentication process help to grant access to an application.

2. What Is a Claim?

A token gets transmitted as a stream of bytes during transmission over a network (intranet/internet). Further, it contains user-specific information in claim format. Each claim includes the user’s name, age, manager’s name, and group name. For receiver-end verification, the token has a digital signature.

A token can have multiple claims:

Let’s say an application wants to know the user’s first name, last name, and email address to allow access and that the user tries to set a connection with the identity provider to obtain a security token.

Before sending the claims to the user, the identity provider will authenticate the user and connect to several sources, including Active Directory.

After authentication, the Security Token Service (STS) will produce a token with desired claims (an email address and first and last names). Finally, the STS signs the token with the identity provider’s private key.

3. How Does Claims-Based Authentication Work?

3.1. Relying Parties

An application that uses the STS of an identity provider for authentication is known as a relying party (RP):   

RPs retrieve user identity data using claims-based identities. In general, the following steps establish trust between the RP and the STS:

• Sharing federation metadata
• Using the RP’s public key, the STS encrypts the tokens
• The RP uses the STS’s public key to verify tokens from STS
• The RP uses its private key to decrypt the token and extract the claims from it

3.2. Claims-Based Authentication: Steps

Let’s illustrate claims-based authentication using the following diagram:

Claims-based authentication involves the following steps: 

• First, the client requests to access the administrator interface of an RP
• Then, the RP redirects the request to a login page for a third party like Google
• The identity provider retrieves identity information from the account store (active directory) and authenticates the user 
• Once the identity provider has successfully validated the user, STS generates a security token with claims and signatures
• When the client receives it from the identity provider, the client sends it to the RP for validation. At this point, RP validates the token and allows access to the desired pages

Following this approach, users can log in to one domain and then gain access to all others that trust the same identity provider.

3.3. Security Token Service

Applications that frequently refer to STS (Ping Identity, Azure AD, Octa) must trust the identity provider to:

• confirm users’ identities
• generate claims with the required credential
• sign the token to keep it secure

Before letting a user use the RP application after receiving a signed token, the third-party identity provider or the application must ensure that the claim is authentic and hasn’t been tampered with.

4. Benefits of Claims-Based Authentication

Now, let’s discuss a few benefits of claim-based authentication.

Users don’t need to set up numerous accounts on various domains and enter their login information each time they need to access a service or application.

Claims-Based Authentication gives an RP a uniform methodology for authentication.

It’s equally important to note that applications won’t be concerned with how identities are validated or where they are stored. Furthermore, identity and applications are loosely coupled in the claims model. 

Also, the RP access won’t change if the entire infrastructure for the identity provider gets changed to biometrics rather than usernames and passwords.

Finally, the identity source, whether from the corporate intranet or a different partner federated organization, is irrelevant because the process includes standardized claims rather than identities.

5. Conclusion

In this article, we discussed the crucial roles of identities, claims, and tokens in authentication for applications.

The claims-based authentication clearly separates identity providers and applications consuming identity. Instead of the application figuring out who the user is, it receives claims to identify the user and any additional attributes it requires.