When configuring an OIDC client, such as an SSO or an OIDC enabled Application, Beyond Identity provides an option to match based on login_hint.
A login hint provides additional parameters that:
-
Lets the authorization server know who the user indicates to be (usually an email address)
-
Can also be a username of a different kind
When a user selects a passkey, if Login Hint Validation is enabled in Beyond Identity, and the OIDC client provides a login_hint, Beyond Identity ensures that the username provided by the client matches the username associated with the Beyond Identity passkey used to authenticate.
If Login Hint Validation is disabled, a user will be logged in and will access the OIDC client application by Beyond Identity based on the passkey used to authenticate, regardless of the username entered.
The login_hint can reduce the likelihood of any confusion of the user that is logged in with a passkey vs. the username that is entered at a login screen of a third party application. A mismatch in the username entered and the passkey used results in a message being displayed to the user and the authentication not completing.
In order to confirm that login_hint is provided by the OIDC client application, review the OIDC_INBOUND events in the Beyond Identity Admin Console.
If this option is enabled and no login_hint is sent by the third-party, the system will default to the user being logged in based on the passkey without matching the username.
To enable a login hint:
- Select Integrations > OIDC tab in the console.
- Add or edit an OIDC client.
- Toggle the Login Hint Validation Config to Enabled.
- Select one or more Login Hint Match Strategies. See the Login Hint Matching Strategies below for more information.
Login Hint Matching Strategies
When validating a login hint, admins can pick any number of the following options. All matching strategies will be attempted in no particular order:
- EMAIL - Match the login hint against the email address stored for the user associated with the credential.
-
EMAIL_LOCAL_PART - Match the hint based on the local part of the email stored for the user associated with the credential.
- Example: john.smith for email address john.smith@example.com
- USER_NAME - Match the hint based on the username stored for the user associated with the credential
-
USER_NAME_LOCAL_PART - Match the hint based on the username part of the email when an SSO requires a username to be in the shape of an email, and in some cases, the username may not match the actual email of the user.
- Example: If the actual email address is john.smith@example.com and the username is jsmith, the username would need to be in the format of jsmith@example.com and the login hint would be jsmith, which matches the “local part” of the username, (i.e., everything before the @). If you do not have an SSO that forces usernames to look like email addresses (for example, the username is just jsmith), USER_NAME_LOCAL_PART strategy will work the same as USER_NAME login hint.
Once a passkey is selected, a provided hint will be matched against the selected strategies until one succeeds and authentication can continue, or they all fail and authentication fails. For authentication failures, users will see the following error:
Note: The error message does not explicitly call out the login hint mismatch for security reasons, but provides an error code that admins and support engineers can interpret as a login hint mismatch failure.
Optimistic Matching
Different SSOs may not provide a login hint depending on authentication flow. Because SSOs do not reliably send Beyond Identity a login hint, and because the user does not control which authentication flow they are in, the login hint is only validated when provided. If the SSO doesn't provide a login hint, no validation is performed. Remember this is not a security feature, so there is no vulnerability here.
Events
Authentication events include login hints when provided. Additionally, if there is a failure due to login hint mismatches, this information will be captured in the Reason section of the authentication event, as shown in the following image.
Comments
0 comments
Article is closed for comments.