Sign-in Consent
Learn about the sign-in consent screen, an extra layer of protection against login CSRF attacks and phishing attempts.
The sign-in consent screen is an extra layer of protection against login CSRF attacks or phishing attempts.
A user may click a link that appears legitimate, but which unknowingly leads them to signing in through a malicious identity provider controlled by an attacker. The sign-in consent screen mitigates this risk by displaying the user’s email and the identity provider’s domain, ensuring the user is aware of how they are signing in to the application.
The sign-in consent screen is an interstitial page that appears during the Single Sign-on flow, after the user has gone through the identity provider (IdP), before redirecting to the application.
This page displays to the user the email returned from the IdP, as well as the IdP origin. With this information, the user must either consent to or deny the sign-in flow.
- Consenting sign-in leads to completing the SSO flow, where the authorization code is forwarded to the application callback.
- Denying the sign-in will result in an SSO session failure and the user will be redirected to the application callback with a
signin_consent_deniederror.
In order to activate the sign-in consent protection, you should go to the Authentication section and enable the sign-in consent checkbox in the Single Sign-On settings.
We recommend using the signin_consent_denied error code to display useful information to the user, so that they can contact their admin and your support team for information about a possible phishing attempt.
When a user denies the sign-in consent, your application’s callback will receive an error response:
For more information about error handling, see the Get Authorization URL error codes documentation.
WorkOS determines whether the sign-in consent screen should be displayed, based on the identity provider, user fingerprint, and SSO flow parameters.
Once a user accepts the sign-in consent screen, the system remembers this approval and avoids displaying the page again for a better user experience.
The sign-in consent screen is always displayed in the following scenarios:
- IdP-initiated flows: The sign-in consent screen is always displayed for IdP-initiated flows (i.e. users clicking on a tile in their IdP), regardless of the identity provider, if the user has not previously approved it.
- Custom SAML or OIDC connections: The sign-in consent screen is displayed for custom connections if the user has not previously approved sign-in consent.
The sign-in consent screen automatically inherits the Admin Portal branding and is served through your custom authentication API domain, if available. Ensure you review the primary button color and logos before enabling this feature. This ensures a trusted experience for your customers.
The sign-in consent is currently only available for Enterprise SSO users, not AuthKit.
If you’re using AuthKit and would like to enable the sign-in consent screen, please reach out to WorkOS support.