Step-Up Authentication with OpenID Connect

What Is Step-Up Authentication?

Step-up authentication is a security mechanism that requires a user to re-authenticate with a stronger level of assurance when accessing sensitive resources or performing critical actions. It ensures that the user requesting access has a verified identity that matches the sensitivity of the operation or data.

For example:

• A user logging into a banking app might initially authenticate with a password to view account balances.
• To transfer funds or access account details, the user might be prompted to provide additional authentication factors, such as a one-time password (OTP) or biometric verification.

When and Why Use Step-Up Authentication?

Most applications use a single level of authentication to verify a user's identity. However, certain scenarios require additional security measures to protect sensitive data or operations. But you don't want to burden users with multi-factor authentication (MFA) every time they log in or access the application. Step-up authentication provides a balance between security and usability by requiring additional authentication only when necessary.

Step-up authentication is commonly used in the following situations:

• Sensitive Operations: Higher security is needed for accessing sensitive resources, such as financial information or confidential data.
• Regulatory Compliance: Compliance with standards like PCI-DSS, HIPAA, or GDPR mandates higher assurance for specific actions.
• Fraud Prevention: Ensures that malicious actors who have stolen basic credentials are blocked when trying to access critical systems or resources.

Implementing Step-Up Authentication with OpenID Connect (OIDC)

If you're using OpenID Connect for authentication, you can implement step-up authentication by leveraging the ID token and its claims. The ID token is a JSON Web Token (JWT) that contains claims about the authentication event and the user. By including specific claims in the ID token, you can enforce step-up authentication based on the user's context or the requested operation.

Step-Up Authentication with the acr Claim

The first thing you need to define are the different levels of authentication by setting Authentication Contexts. These contexts represent the strength of the authentication process and can be used to determine when step-up authentication is required. It is a common vocabulary shared between the authentication server and the client application.

The acr (Authentication Context Class Reference) claim in the ID token represents the authentication context class reference during the process. It indicates the level of assurance provided by the authentication process for the user in the current session. For example: acr=loa1 represents a basic level of assurance, such as password-based authentication.

When a user authenticates, the authentication server includes the acr claim in the ID token based on the level of assurance provided. Your application can then evaluate the acr claim to determine if step-up authentication is required for the requested operation.

OpenID Connect specifies common values for the acr claim, but you can define custom values based on your application's requirements. The most common value is http://schemas.openid.net/pape/policies/2007/06/multi-factor, which indicates that multi-factor authentication was used during the authentication process.

Example of Step-Up Authentication scenario

Let's consider a scenario where a user logs into an application to view their account balance. The initial authentication process uses a password-based authentication method. When the user tries to transfer funds, the application requires step-up authentication and prompts the user to provide a one-time password (OTP).

1. The user logs in with their username and password. The application sends an authentication request to the OpenID Connect provider as follows:

GET /authorize?
  response_type=code
  &client_id=client_id
  &redirect_uri=https://app.example.com/callback
  &scope=openid
  &state=state
  &nonce=nonce

After successful authentication, the OpenID Connect provider issues an ID token with the following payload:

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "exp": 1635200000,
  "iat": 1635196400,
  "amr": ["pwd"]
}

2. The user initiates a fund transfer operation. The application evaluates the amr claim in the ID token and determines that the user authenticated using a password. Since the operation requires a higher level of assurance, the application prompts the user to provide an OTP.

The application sends a new authentication request to the OpenID Connect provider with the acr_values parameter set to http://schemas.openid.net/pape/policies/2007/06/multi-factor:

GET /authorize?
  response_type=code
  &client_id=client_id
  &redirect_uri=https://app.example.com/callback
  &scope=openid
  &state=state
  &nonce=nonce
  &acr_values=http://schemas.openid.net/pape/policies/2007/06/multi-factor

Now, the OpenID Connect provider issues a new ID token with the following payload:

{
  "iss": "https://auth.example.com",
  "sub": "1234567890",
  "aud": "https://api.example.com",
  "exp": 1635200000,
  "iat": 1635196400,
  "amr": ["pwd", "otp"],
  "acr": "http://schemas.openid.net/pape/policies/2007/06/multi-factor"
}

You are now able to enforce step-up authentication based on the acr claim in the ID token. By evaluating the acr claim, you can determine when to prompt users for additional authentication factors.