Levels of authentication

SafeNet Trusted Access (STA) supports Authentication Context Class Reference (ACR) and Authentication Methods Reference (AMR) in OpenID Connect (OIDC) authentication flows. This capability enables applications to request, enforce, and validate specific authentication assurance levels as part of their access policies.

This feature improves interoperability with identity-driven applications and strengthens overall security by allowing services to verify not only that the user authenticated, but also how and at what assurance level the authentication was performed.

When ACR values are provided in an authentication request, STA evaluates them against the configured authentication policies to determine the effective Level of Authentication (LoA). If multiple ACR values are requested, STA enforces only those that the applicable policies permit.

• If the request includes urn:safenetid.com:acr:fido and urn:safenetid.com:acr:grid, but the STA policy allows only OTP-based authentication, all non-OTP ACR values are ignored and authentication proceeds using OTP.

• If the request specifies an ACR value that the configured policies do not permit (for example, only urn:safenetid.com:acr:fido when OTP is the only allowed method), the authentication request fails due to an unmet LoA requirement.

What is ACR?

ACR is an OIDC mechanism that allows a client application to request a specific LoA when initiating an authentication request. By including the acr_values parameter in an authorization request, the application can indicate the assurance level required to access the service.

STA evaluates the requested ACR value and ensures that the resulting authentication meets the specified LoA.

What is AMR?

AMR provides detailed information about the authentication mechanisms that are used during the user’s login session. These values are returned in the ID token and access token, and reflect the specific authentication steps that were executed.

Supported ACR values

AMR values are specific to each identity provider (IDP) and can vary across different IDPs. Refer to the corresponding template documentation for the list of supported AMR values.

OIDC use cases using ACR and AMR

This section describes use cases that demonstrate how OIDC clients can use ACR and AMR with STA.

These use cases show how relying parties can:

• Use ACR values to request specific authentication methods for a transaction.

• Use AMR claims to verify the authentication methods that STA performs.

When you combine these OIDC features with STA authentication policies, you can enforce authentication requirements dynamically, while maintaining standards-based interoperability and centralized policy control.

The following examples use the Postman application for describing use cases that show how ACR and AMR values are received in the generated ID token, and for use cases related to multi-factor authentication (MFA).

Use case 1: ACR-based authentication enforcement with multiple OTP authenticators

This use case demonstrates how STA enforces authentication based on the acr_values parameter provided in an OIDC authentication request, even when multiple OTP-type authenticators are configured for a user.

Configuration

• Create an OIDC application using the generic template.

  • Configure a custom OIDC scope for the application.

    

• Configure multiple STA authentication policies (primary only for this use case).

  

• Assign multiple authenticators of type OTP (MobilePass+, GrIDsure) to the user.

Flow

1. The OIDC client initiates an authentication request containing a specific acr_value:

   urn:safenetid.com:acr:grid

   

2. STA evaluates the applicable primary authentication policies to determine the authentication flow.

3. STA enforces the authentication method flow based on STA policies and aligns it with the ACR value that is provided, regardless of other authenticators assigned to the user.

   In this case, MobilePass+ and GrIDsure tokens are already assigned to the user, however the application forces the user to authenticate using the GrIDsure authenticator, because the STA OTP policy is filtered using the ACR value that is provided.

   

4. The user completes the requested authentication method driven by the STA policies and filtered by the ACR values that are provided.

   

5. STA returns a successful authentication response, including any custom scopes requested by the client.

   

Result

Authentication is enforced according to the requested ACR value, while the overall authentication flow remains governed by the STA policy configuration.

Use Case 2: MFA and assurance validation using ACR and AMR

This use case demonstrates how multiple ACR values can be used to enforce MFA, and how the achieved authentication methods are reflected in the AMR claim.

Configuration

• Create an OIDC application using the generic template.

  • Configure the application to support ACR and AMR claims.

• For achieving MFA, assign the user with authenticators, such as LDAP password, GrIDsure, MobilePass+, and FIDO token.

• Configure STA policies as follows:

  • Primary: FIDO + OTP (GrIDsure)

  • Secondary: LDAP + OTP

  

Flow

1. The OIDC client initiates an authentication request with multiple ACR values.

   • urn:safenetid.com:acr:grid
   • urn:safenetid.com:acr:fido

   

2. STA evaluates the request and enforces each authentication method as required. (Suppose the user is performing login using the primary authentication flow, which is FIDO+OTP.)

   • It first asks the user for FIDO authentication, and then the next authenticator is enforced according to the policy and ACR combination.

   • The ACR is urn:safenetid.com:acr:grid and urn:safenetid.com:acr:fido, which means that GrIDsure token validation is enforced for second factor authentication as OTP, even if the user already has other types of OTP token assigned.

   Even if only one urn:safenetid.com:acr:grid ACR is provided in the authentication request, the authentication flow works as FIDO+OTP because the flow is derived from STA policies and ACR only does the filtering.

3. The user completes all required authentication steps.

4. After successful authentication, STA issues an ID token that contains the AMR claim, which consists of the following:

   • fido
   • otp
   • mfa

   

Result

The ID token accurately reflects the authentication methods used during the transaction through the AMR claim. Relying parties can validate the actual authentication assurance level achieved during login and make informed authorization decisions based on standardized AMR values.

ACR-AMR mapping table

The following table provides an overview of the options: