Interface: XmBindIdRequest

Shared parameters for a BindID request configuration.

Hierarchy

Properties

boundTo

• Optional boundTo: XmBindIdBoundTo | null

Used to require an authenticating device bound to the Client Application for a specified user (e.g., for step-up authentication). This bound status is reflected in the ID token by the ts.bindid.app_bound_cred ACR value, which is set using a session-feedback request.

customMessage

• Optional customMessage: string | null

Optional. A custom message to present as part of the authentication context detail screen.

encrypted

• Optional encrypted: boolean | null

A flag indicates whether the authentication request should be encrypted.

loginHint

• Optional loginHint: XmBindIdLoginHint | null

Optional. Type and value for the login hint, which is used as a hint for the user’s login identifier (e.g., their email address)

nonce

• Optional nonce: string | null

Optional. A nonce value to be included in the generated ID Token. This is typically provided by the application backend, and can be used to ensure at the backend that the authentication response corresponds to a specific request issued by the application.

redirectUri

• redirectUri: string

URL to which BindID will redirect on process completion, to convey results back to the calling application.

scope

• Optional scope: Array<XmBindIdScopeType> | null

Optional. A set of BindID scopes that will include additional information in the result claims. If not provided, only 'Openid' scope is sent

state

• Optional state: string | null

Optional. A state value to be included in the BindID response issued through redirect. This is typically generated at the front-end, and verified at the front-end upon processing the redirect. This ensures that the redirect request corresponds to the BindID authentication request.

verifications

• Optional verifications: Array<XmRequiredVerifications> | null

A collection of verifications to try and execute for this request. It is not guaranteed that each requested verification will be fulfilled. The acr claim of the resulting access token should be examined to determine which verifications were fulfilled.