<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content

Explanation of Suspicious Activity Events (Single Sign On)

Single Sign-On
Okta Classic Engine
Okta Identity Engine

Overview

This article aims to provide an explanation of different suspicious activity events that are logged. 

Applies To

  • Suspicious Activity Events
  • Single Sign On (SSO)

Solution

  1. The transformed username '${okta_username}' was rejected by the username filter.
    • This event occurs during authentication via an external Identity Provider (IdP) when Okta receives a username (possibly transformed using an expression or mapping) and checks it against a predefined username filter (such as a regular expression).
    • If the transformed username does not match the filter criteria, Okta rejects the authentication attempt.
  2. Unable to validate incoming Security Assertion Markup Language (SAML) Assertion: [${token_id}] - ${error_message}.
    • This event is triggered when Okta receives a SAML assertion from an external Identity Provider (IdP) but cannot validate it.
    • The failure to validate may be due to issues such as an invalid signature, incorrect assertion format, expired assertion, or other SAML protocol errors.
    • The ${error_message} will provide more specific information about why the validation failed, which can help in troubleshooting the exact cause.
  3. A SAML Assertion with the same ID [${token_id}] has already been processed by Okta for a previous request.
    • This event indicates that Okta has received a SAML assertion with an ID that has already been used in a previous authentication request.
    • Okta maintains a replay cache to prevent replay attacks, which means it will reject any assertion that reuses an ID within a certain time window.
    • This situation can happen if a user tries to reuse a browser tab or if an application is set to automatically reload or resend the same SAML assertion.
  4. Unable to validate SAML Response [ID=${message_id}] - 'InResponseTo=${in_response_to}' does not match the ID of a SAML authentication request sent from Okta.
    • This event occurs when Okta receives a SAML response from an Identity Provider (IdP), but the InResponseTo field in the response does not match any SAML authentication request previously sent by Okta.
    • The InResponseTo field is used to correlate the SAML response with the original authentication request.
    • This mismatch can happen if the SAML response is delayed or reused, or if the SAML flow is misconfigured.
    • As a result, Okta cannot validate the response, and the authentication attempt fails.
    • If a custom login page is used, be aware that SAML request parameters may not be preserved, which can also lead to this issue.

 

Related References

Loading
Okta Support - Explanation of Suspicious Activity Events (Single Sign On)