Your suggested change has been received. Thank you.

close

Suggest A Change

https://thales.na.market.dpondemand.io/docs/dpod/services/kmo….

Thales Logo

All

  • All
back

Previews

STA integration with Entra ID EAM

search

STA integration with Entra ID EAM

This feature enables customers with Microsoft Entra ID to use SafeNet Trusted Access (STA) to provide an external authentication method (EAM). EAM allows you to integrate external authentication providers, like STA, to satisfy the multi-factor authentication (MFA) requirements for the resource or application to which access is requested. STA can satisfy the second factor of an MFA requirement. Microsoft Entra ID can specify the authentication strength and method that STA must use.

STA as second factor

When a user attempts to access a resource, they must first use an authentication method (for example, password) that is validated by Entra ID and then use additional complementary authentication methods (for example, MobilePASS+ or GrIDsure) that are validated by STA.

Note

External authentication methods in Microsoft Entra ID is a Microsoft product that is in public preview.

STA integration with Entra ID EAM is a public preview. It is subject to change based on customer feedback and feature evolution by Thales or Microsoft. Contact Thales Customer Support to request access.

Workflow for STA integration as Microsoft Entra ID EAM

The following illustration shows the workflow:

Workflow for integration of STA as Microsoft Entra Id EAM

  1. The user tries to access an app that is protected by Entra ID.

  2. The Entra ID login page is displayed for the user.

  3. The user authenticates with their primary authentication method. Entra ID processes the policies for the user and determines that an additional authentication method is required.

  4. The user chooses an external authentication method (EAM) as their second authentication method. Entra ID redirects the user's browser session to the URL for the external authentication method.

    a. This URL comes from the DISCOVERY ENDPOINT that you provide when you create the external authentication method.

    b. The app provides an expired or near-expired token that contains information identifying the user and tenant.

  5. The external authentication provider asks the user to provide the second authentication method (second-factor of authentication).

  6. The user provides the credentials that are required.

    1. The external authentication provider validates that the token came from Entra ID and checks the contents of the token.

    2. The external authentication provider performs any actions it deems necessary, such as authenticating the user with some credential.

  7. The external authentication provider redirects the user back to Entra ID with a valid ID token that contains the claims required for verification.

  8. Entra ID validates that the token's signature came from the configured external authentication provider and then checks the contents of the token. Entra ID also compares the claims in the token to the required claims.

  9. If the claims meet the required claims list, the user has satisfied the requirement. If the user satisfies any additional policy requirements, authentication succeeds and the access token is issued satisfying MFA.

  10. The user accesses the app.

Configure STA as a Microsoft Entra ID EAM

  1. On the STA Access Management console, go to the Applications tab and select Add application.

    Add application

    The Add Application dialog box lists all of the application templates and indicates the application type, such as SAML, OIDC, or agent.

  2. Search and select Entra Id External Authentication Method, rename the application as needed, and then select Add.

  3. Follow the steps in the help file. You can click Help Documentation to view the documentation.

Add an EAM using Microsoft Graph

Using the Microsoft Graph API to add an EAM is optional.

To add the external authentication method:

  1. Call the Microsoft Graph authentication methods policy endpoint.

  2. Post the properties of the APP ID, CLIENT ID, and DISCOVERY ENDPOINT that you copied from the Entra Id External Authentication Method app in STA:

    • AppId
    • ClientId
    • DiscoveryEndpoint

Note

To manage this policy, you need the Policy.ReadWrite.AuthenticationMethod permission.

Unless you set specific groups, the authentication method applies to all users. Information about obtaining group IDs is available here

Sample request: Post to create the authentication method 

    POST 
    https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations 
    {
        "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration", 
        "displayName": "Adatum", 
        "appId": "600b719b-3766-4dc5-95a6-3c4a8dc31885", 
        "openIdConnectSetting": { 
            "clientId": "06a011bd-ec92-4404-80fb-db6d5ada8ee2", 
            "discoveryUrl": "https//Adatum.com/.well-known/openid-configuration" 
        } 
    }

Sample response

On success, a 201 is returned:

    HTTP/1.1 201 CREATED 
    { 
        "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration", 
        "id": "b3107ab7-68c7-4553-a167-48c8c2c24d52", 
        "displayName": "Adatum", 
        "appId": "600b719b-3766-4dc5-95a6-3c4a8dc31885", 
        "openIdConnectSetting": { 
            "clientId": "06a011bd-ec92-4404-80fb-db6d5ada8ee2", 
            "discoveryUrl": "https//Adatum.com/.well-known/openid-configuration" 
        }, 
        "state": "disabled", 
        "excludeTargets": [] 
    }

Add an EAM using the Entra admin center

  1. In the Microsoft Entra ID Admin Centre, navigate to Security > Authentication methods > Policies.

  2. Select Add external method (Preview).

    alt_text

  3. Enter the Name, AppId, ClientId, and DiscoveryEndpoint used in Configure STA as an EAM in Entra ID.

    alt_text

To grant consent for the application (AppID) that you want to add to a tenant, you must have either Global Administrator or Privileged Role Administrator permissions.

If you add the external authentication method using the Entra admin center, you are prompted to grant consent for the application. The EAM is not enabled until the app has the required permissions in the tenant. If you add the method using an API, ensure that the EAM is disabled until the application has granted consent.

You can add the app to multiple tenants. Complete this step before adding the external authentication method to the Entra ID authentication methods policy.

Update the EAM using Microsoft Graph

Use the following call to get the configuration:

    GET https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/b3107ab7-68c7-4553-a167-48c8c2c24d52 

    HTTP/1.1 200 OK 
    { 
        "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration", 
        "id": "b3107ab7-68c7-4553-a167-48c8c2c24d52", 
        "displayName": "Adatum", 
        "appId": "fb263304-618c-4ffb-878a-1f4490bdf200", 
        "openIdConnectSetting": { 
            "clientId": "06a011bd-ec92-4404-80fb-db6d5ada8ee2", 
            "discoveryUrl": "https//Adatum.com/.well-known/openid-configuration" 
        }, 
        "state": "disabled", 
        "excludeTargets": [], 
        "includeTargets": [] 
    }

To make changes to the authentication method, use PATCH calls. You can change the include targets, the method state, or the openIdConnectSetting values. The displayName for the method cannot be changed. 

    PATCH https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/b3107ab7-68c7-4553-a167-48c8c2c24d52 
    { 
        "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration", 
        "includeTargets": [
            { 
                "targetType": "group", 
                "id": "b185b746-e7db-4fa2-bafc-69ecf18850dd", 
                "isRegistrationRequired": false, 
            } 
        ], 
        "state": "enabled" 
    } 

HTTP/1.1 204 NO CONTENT

Sample response

    HTTP/1.1 200 OK 
    { 
        "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration", 
        "id": "b3107ab7-68c7-4553-a167-48c8c2c24d52", 
        "displayName": "Adatum", "appId": "fb263304-618c-4ffb-878a-1f4490bdf200", "openIdConnectSetting": { 
            "clientId": "06a011bd-ec92-4404-80fb-db6d5ada8ee2", 
            "discoveryUrl": "https//Adatum.com/.well-known/openid-configuration" 
        }, 
        "state": "enabled", 
        "includeTargets": [ 
            { 
                "targetType": "group", 
                "id": "b185b746-e7db-4fa2-bafc-69ecf18850dd", 
                "isRegistrationRequired": false, 
            } 
        ], 
        "excludeTargets": [] 
    }

Delete an EAM

If you no longer want your users to use the external authentication method, you can either update the state to disabled or delete the method. In the following example, the method is deleted using Microsoft Graph:

    DELETE https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/b3107ab7-68c7-4553-a167-48c8c2c24d52 

    HTTP/1.1 204 NO CONTENT

Find STA metadata using OIDC discovery

STA provides an OIDC discovery endpoint for retrieving additional configuration data. The full URL, including .well-known/oidc-configuration, must be included in the discovery URL configured when creating the external authentication method. The endpoint returns a provider metadata JSON document that is hosted there. The endpoint also returns the valid content-length header.

The OIDC document specifying the values for STA metadata can be found here.

The following table lists the data that is present in STA's metadata.

Metadata value Value Comments
Issuer This URL should match both the host URL used for discovery and the iss claim in the tokens issued by STA.
authorization_endpoint The endpoint that Entra ID communicates with for authorization. This endpoint must be present as one of the reply URLs for the allowed apps.
jwks_uri The location of the public keys needed to verify the signatures issued by STA.
NOTE: The JWK x5c parameter must be present to provide X.509 representations of the keys that are provided.
scopes_supported openid Other values can also be included.
response_types_supported id_token Other values can also be included.
subject_types_supported
id_token_signing_alg_values_supported Microsoft supports RS256.
claim_types_supported normal Optional. Other values can also be included. 
    http://customcaserver.azurewebsites.net/v2.0/.well-known/openid-configuration 
    { 
        "authorization_endpoint": "https://customcaserver.azurewebsites.net/api/Authorize", 
        "claims_supported": [ 
            "email" 
        ], 
        "grant_types_supported": [ 
            "implicit" 
        ],
        "id_token_signing_alg_values_supported": [ 
            "RS256" 
        ], 
        "issuer": "https://customcaserver.azurewebsites.net", 
        "jwks_uri": "http://customcaserver.azurewebsites.net/.well-known/jwks", 
        "response_modes_supported": [ 
            "form_post" 
        ], 
        "response_types_supported": [ 
            "id_token" 
        ], 
        "scopes_supported": [ 
            "openid" 
        ], 
        "SigningKeys": [], 
        "subject_types_supported": [ 
            "public" 
        ] 
    }

    http://customcaserver.azurewebsites.net/.well-known/jwks 
    { 
        "keys": [ 
            { 
                "kty": "RSA", 
                "use": "sig", 
                "kid": "CEYm9GmLvfIqrl0zBJc9-Chk_LM", 
                "x5t": "CEYm9GmLvfIqrl0zBJc9-Chk_LM", 
                "n": "jq277LRoE6WKM0awT3b-—redacted--vt8J6MZvmgboVB9S5CMQ", 
                "e": "AQAB", 
                "x5c": [ 
                    "cZa3jEzEd0nvztzAVM6Uy—redacted--Z0HBHjTZq9IWiPHSWo0rzA=" 
                ] 
            } 
        ] 
    }

STA metadata caching

Entra ID caches STA’s metadata and refreshes it every 24 hours. To roll-over the cached keys:

  1. Publish the Existing Cert and New Cert in the jwks_uri.

  2. Keep signing with the Existing Cert, until the Entra ID cache is refreshed, expired, or updated (every two days).

  3. Switch to signing with New Cert.

The schedules for key rollovers are not published. The dependent service must be prepared to handle both immediate and periodic rollovers. It is best practice to use a dedicated library built for this purpose, such as azure-activedirectory-identitymodel-extensions-for-dotnet. Refer to Signing key rollover in Entra ID for details.

Entra ID metadata discovery

Similar to Entra ID using discovery to retrieve the public keys of tokens issued by STA, STA must retrieve the public keys of tokens issued by Entra ID.

Entra ID’s metadata discovery endpoint:

Using the public key identifier from the token (the “kid” from JWS), you can determine which of the keys retrieved from the jwks_uri property to use for validating the Entra ID token signature.

Validating tokens issued by Entra ID

For information about how to validate the tokens issued by Entra ID, see ID tokens in the Microsoft identity platform.

For information about token validation, see Microsoft’s token validation library.

When validation succeeds, you can use the claims payload to get details about the user and their tenant.

Entra ID call to STA

Entra ID uses the OIDC implicit flow to communicate with STA. Using this flow, communication with STA is done exclusively via STA's authorization endpoint. To let STA know the user for whom Entra ID is making the request, Entra ID provides a token in the id_token_hint parameter.

This call is made through a POST request.

The authentication request parameters are:

Authentication query parameter Value Description
scope openid
response_type Id_token The value used for the implicit flow
response_mode form_post Used to avoid issues with large URLs.
client_id The ID given to Entra ID by STA. See Configure STA as an EAM in Entra ID.
redirect_uri The URI to which the response (id_token_hint) is sent by STA.
For example,
<input type="hidden" name="redirect_uri" value="https://login.microsoftonline.com/common/federation/externalauthprovider" />
This should be registered with STA off-band. The redirect URIs that can be sent are:
- Azure Global
nonce A random string generated by Entra ID. It can be the session ID. If provided, it needs to be returned in the response to Entra ID as explained in Entra ID processing of the response from STA.
state If provided, STA returns this in its response. Entra ID uses the state to keep context about the call.
id_token_hint A token issued by Entra ID for the user and provided to STA. See Default Id_token_hint claims.
claims A JSON blob containing the claims requested. For details about the format of this parameter, see the section about the claims request parameter from the OIDC documentation .
An example of this (decoded) for an authentication where an external authentication method satisfies MFA follows.
{ "id_token": { "acr": { "essential": true, "values":["possessionorinherence"] }, "amr": { "essential": true, "values": [face", "fido", "fpt", "hwk", "iris", "otp", "pop", "retina", "sc", "sms", "swk", "tel", "vbm"] } } }
This is provided to help STA know which claims Entra ID expects from it.
The combination of the ACR and AMR values are used by Entra ID to validate that the authentication method used for second factor satisfies the MFA requirement that it differs in type from what was completed for first factor with Entra ID.
client-request-id A guid value This can be logged by STA and used for troubleshooting.

Note

Any parameters in the request that are not listed in this document should be ignored.

Id_token_hint claims

The following table describes the required content of the token passed as id_token_hint in the request made to STA.

Claim Description
iss The security token service (STS) that constructs and returns the token, and the Entra ID tenant in which the user was authenticated.
Your app should use the GUID portion of the claim to restrict the set of tenants that can sign in to the app, if applicable.
The issuer should match the issuer URL from the signed-in user’s tenant’s OIDC discovery JSON metadata.
aud The audience should be set to STA’s client ID for Entra ID.
exp The expiration time is set to expire a short time after the issuing time (to avoid timeskew issues). This token is not meant for authentication, so there is no reason for its validity to outlast the request by much.
iat Issuing time – Set as usual.
tid The tenant ID for advertising the tenant to STA. Represents the Entra ID tenant that the user is from.
oid The immutable identifier for an object in the Microsoft identity platform, which is a user account in this case. It can also be used to perform authorization checks safely, and used as a key in database tables. This ID uniquely identifies the user across applications. Two different applications signing in the same user receive the same value in the oid claim. Thus, oid can be used when making queries to Microsoft online services, such as the Microsoft Graph.
preferred_username Provides a human readable value that identifies the subject of the token. This value is not guaranteed to be unique within a tenant and is designed to be used only for display purposes.
sub Subject identifier for the user at the issuer. The user of an app about which the token asserts information. This value is immutable and cannot be reassigned or reused. It can be used to access a resource and as a key in database tables. The subject is always present in the tokens that Entra ID issues. You can use this value in a general-purpose authorization system.
The subject is, however, a pairwise identifier. It is unique to a particular application ID. Therefore, if a single user signs in to two different apps using two different client IDs, those apps receive two different values for the subject claim. This may or may not be desired, depending on your architecture and privacy requirements.
See also the oid claim (which does remain the same across apps within a tenant).

To prevent the token from being used for anything other than a hint, it is issued as expired. The token is signed, and can be verified using the published Azure AD’s discovery metadata.

email and upn claims

If a provider needs upn or email claims for discovery, you can configure these optional claims for id_token following this documentation. If requested, email is always returned. If upn is requested, it is returned for user accounts that are members of the directory, but not for guest accounts.

Note

An email claim is not guaranteed to be unique. Use unique claims to link accounts. See: Migrate away from using email claims for user identification or authorization.

It is a best practice to associate accounts on the provider side with the account in Entra ID via the oid and tid claims. These two claims are guaranteed to be unique for the account in the tenant.

Example id_token_hint

An example of an id_token_hint for a directory member follows.

    { 
        "typ": "JWT", 
        "alg": "RS256", 
        "kid": "7_Zuf1tvkwLxYaHS3q6lUjUYIGw" 
    }.  { 
        "ver": "2.0", 
        "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0", 
        "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA", 
        "aud": "600b719b-3766-4dc5-95a6-3c4a8dc31885", 
        "exp": 1536093790, 
        "iat": 1536093791, 
        "nbf": 1536093791, 
        "name": "Test User 2", 
        "preferred_username": "testuser2@contoso.com" 
        "oid": "951ddb04-b16d-45f3-bbf7-b0fa18fa7aee", 
        "tid": "14c2f153-90a7-4689-9db7-9543bf084dad" 
        }.

An example of the id_token hint for a guest user in the tenant follows. 

    { 
        "typ": "JWT", 
        "alg": "RS256", 
        "kid": "7_Zuf1tvkwLxYaHS3q6lUjUYIGw" 
    }.  {
        "ver": "2.0", 
        "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0", 
        "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA", 
        "aud": "600b719b-3766-4dc5-95a6-3c4a8dc31885", 
        "exp": 1536093790, 
        "iat": 1536093791, 
        "nbf": 1536093791, 
        "name": "External Test User (Hotmail)", 
        "preferred_username": "externaltestuser@hotmail.com", 
        "oid": "951ddb04-b16d-45f3-bbf7-b0fa18fa7aee", 
        "tid": "14c2f153-90a7-4689-9db7-9543bf084dad" 
        }

The following are examples of an id_token_hint if the claims for upn and email are configured.

An example of an id_token_hint for a directory member follows. 

    { 
        "typ": "JWT", 
        "alg": "RS256", 
        "kid": "7_Zuf1tvkwLxYaHS3q6lUjUYIGw" 
    }.  { 
        "ver": "2.0", 
        "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0", 
        "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA", 
        "aud": "600b719b-3766-4dc5-95a6-3c4a8dc31885", 
        "exp": 1536093790, 
        "iat": 1536093791, 
        "nbf": 1536093791, 
        "name": "Test User 2", 
        "preferred_username": "testuser2@contoso.com" 
        "upn": "testuser2@contoso.com" 
        "oid": "951ddb04-b16d-45f3-bbf7-b0fa18fa7aee", 
        "tid": "14c2f153-90a7-4689-9db7-9543bf084dad" 
        }

An example of the id_token hint for a guest user in the tenant follows. Note that the upn claim is not returned. 

    { 
        "typ": "JWT", 
        "alg": "RS256", 
        "kid": "7_Zuf1tvkwLxYaHS3q6lUjUYIGw" 
    }.  { 
        "ver": "2.0", 
        "iss": "https://login.microsoftonline.com/9122040d-6c67-4c5b-b112-36a304b66dad/v2.0", 
        "sub": "mBfcvuhSHkDWVgV72x2ruIYdSsPSvcj2R0qfc6mGEAA",
        "aud": "600b719b-3766-4dc5-95a6-3c4a8dc31885", 
        "exp": 1536093790, 
        "iat": 1536093791, 
        "nbf": 1536093791, 
        "name": "External Test User (Hotmail)", 
        "preferred_username": "externaltestuser@hotmail.com", 
        "email": "externaltestuser@hotmail.com", 
        "oid": "951ddb04-b16d-45f3-bbf7-b0fa18fa7aee", 
        "tid": "14c2f153-90a7-4689-9db7-9543bf084dad" 
        }

Validation steps for STA

The following steps are suggested for validating STA as an external authentication method. You are encouraged to take additional steps.

  1. From the request:

    1. Ensure that the redirect_uri is one of the published URIs provided in the Entra ID call to STA.

    2. Ensure that the client_id has a value that you assigned to Entra ID.

    3. Validate the id_token_hint that is presented to STA by Entra ID.

  2. (Optionally) From the claims in the id_token_hint, make a call to Microsoft Graph to fetch additional details about the user, such as oid and tid. For details, see id_token_hint claims.

  3. Test the remaining STA authentication and authorization functions.

  4. Send a response to Entra ID as explained in Entra ID processing of the response from STA.

Entra ID processing of the response from STA

STA will POST a response to the redirect_uri detailed in Entra ID call to STA. A success response provides the following parameters:

Parameter Description
id_token The token issued by STA
state The same state that was passed in the request, if any

On success, the provider issues an id_token for the user. Entra ID uses the published OIDC metadata to verify that the token contains the expected claims as well as all the other token validations that OIDC requires.

Claim Description
iss Issuer must match the issuer from the provider’s discovery metadata.
aud Audience is the Entra ID client id.
exp Expiration time, set as usual.
iat Issuing time, set as usual.
sub Subject must match the sub from the id_token_hint sent to initiate this request.
nonce The same nonce that was passed in the request, if any. Otherwise, this should not be present.
acr The acr claims for the authentication request. This should match one of the values from the request sent to initiate this request. Only one acr of the following claims should be returned:
possessionorinherence Authentication must take place with a possession- or inherence-based factor.
amr The amr claims for the authentication method used in authentication. Only one method claim should be returned. The supported claims are:fido FIDO was usedhwk Proof of possession of hardware-secured keyotp One-time passwordsc Smart card
sms Confirmation by SMS to a registered number
swk Proof of presence of a software-secured key
tel Confirmation by telephone

Note

Because Entra ID requires MFA to be satisfied to issue a token with MFA claims, only methods with a different type (something you have (possession), something you know (knowledge), something you are (inherence)), can be used to satisfy the second factor.

Entra ID validates the type mapping based on the following table:

Claim Method type Notes
fido Possession FIDO was used. Some implementations can also require biometric, but possession is mapped because it is the primary security attribute.
hwk Possession Proof of possession of hardware-secured key
otp Possession One-time password
pop Possession Proof of possession
sc Possession Smart card
sms Possession Confirmation by SMS to registered number
swk Possession Proof of presence of a software-secured key
tel Possession Confirmation by telephone

If no issues are found with the token, then Entra ID considers that MFA has been satisfied and issues a token to the user. Otherwise, it fails the user’s request.

Failure is indicated by issuing Error Response parameters:

Parameter Description
Error An ASCII error code, such as access_denied or temporarily_unavailable.

Entra ID considers the request successful if the id_token parameter is present in the response and the token is valid. Otherwise, the request is considered unsuccessful and Entra ID fails the original authentication attempt due to the policy requirements as dictated by the conditional access policy.

Entra ID abandons the state of the authentication attempt on its end approximately 10 minutes after the redirection has occurred to the provider.

Transition period for acr and amr claims integration

The initial preview support for external authentication methods replicated the values of the amr claim in the acr claim, and no values were provided by Entra ID in the amr claim. The provider needed to provide the same value in the amr and acr claims in the ID token returned to Entra ID.

The Public Preview release uses the updated approach where:

  1. acr claim values align with the method type-based factor (inherence, possession, knowledge, or the conjoined versions).
  2. Values the methods accepted for satisfying the authentication are included in the amr claim in the request.

A transition period supporting the initial preview testing will be enabled to give providers time to update their integration. During this transition period the following approach will be used:

  1. acr claim values will include the same values of the current integration and the method-type based values (for example, possessionorinherence) that will be used moving forward.

  2. The acceptable values for the amr claim will be included in the request from Entra ID.

During this transition time, providers can return an acr value in the id_token that is either the method type-based value (possessionorinherence) or a method value. If the method value is returned, then the amr and acr values must match.

Phase acr values from Entra ID amr values from Entra ID acr values accepted by Entra ID amr values accepted by Entra ID
Current behavior Values matching the acceptable methods for authentication None One value from the list emitted by Entra ID. Value must match what is returned in the amr claim, appropriate for the method the user performed for authentication. One value from the list of values emitted by Entra ID in the acr. Value must match what is returned in the acr claim, matching the method the user performed for authentication.
Transition Method type-based values (possession, inherence, possessionorinherence), as well as the list of values matching acceptable methods Values that will be accepted for satisfying authentication. During this period, this list will match the method values included in the acr claim Entra ID populates. One value from the acr values needs to be returned appropriate for the authentication the user performed. If a method-value is returned, it must match the value that is returned in amr. One value from the list of values set by Entra ID as part of the request in the amr or acr, matching the method the user performed for authentication.
Final behavior Method type-based values (possession, inherence, possessionorinherence) Values matching the acceptable methods for authentication One of the acr values set by Entra ID, matching the type of method the user performed for authentication. One value from the list of values set by Entra ID as part of the request in the amr, matching the method the user performed for authentication.

Entra ID error response handling

Services in the Microsoft Entra ID platform use a correlationId to correlate calls across various internal and external systems. It serves as a common identifier of the whole operation (or flow) potentially involving multiple HTTP calls. When an error occurs during any of the operations, the response will contain a filed named Correlation Id.

When reaching out to Microsoft support or similar service, provide the value of this Correlation ID because it makes accessing the telemetry and logs faster.

Example

ENTRA IDSTS70002: Error validating credentials. ENTRA IDSTS50012: External ID token from issuer 'https://sts.XXXXXXXXX.com/auth/realms/XXXXXXXXXmfa' failed signature verification. KeyID of token is 'Rk3vlP4vD3OMJzBvrig81pnvaMqA'
Trace ID: 01c2cd09-8997-45bf-bfe4-18fdf9d1a101
Correlation ID: 72826bb4-abb7-4221-b253-100f530b4b0a
Timestamp: 2023-07-24 16:51:34Z

Custom controls and external authentication methods

In Entra ID, external authentication methods and custom controls can operate in parallel while you prepare to migrate to external authentication methods.

If you are currently using an integration with an external provider via custom controls, you can continue to use the custom control and any configured Conditional Access policies to manage your authentication requirements for resources. It is a best practice to create a parallel set of Conditional Access policies during the migration period:

  • The policies should use the Require multifactor authentication grant control instead of the Custom Control grant.

    Note

    Grant controls based on authentication strengths, including the built-in MFA strength, will not be satisfied by the external authentication method. Authentication strengths support for external authentication methods is not yet available.

  • Test the new policy first with a subset of users. Exclude the test group from the policy that requires the custom controls and include it in the policy that requires multi-factor authentication. After successful completion of the test, move the policy configured for custom controls to off.

On this page