I'm adding Google-based SSO to an existing application where sensitive actions currently require the user to re-enter their password, such as changing security settings or performing destructive operations. SSO users do not have a local application password, so I'm deciding how to replace that confirmation step.
Possible approaches include requesting step-up authentication from the identity provider, requiring MFA or WebAuthn, sending a one-time code by email, or creating a separate application password. The application also has an old security-question feature, although using that for sensitive actions seems questionable.
My main concern is whether SSO re-authentication provides meaningful extra security when the user already has an active Google session. If the identity provider silently reuses that session, the user may not provide any new proof of identity. What pattern would you recommend for confirming sensitive actions for SSO users?
4 Answers
A short-lived email OTP can be a practical fallback for destructive actions when provider step-up authentication isn’t available, but it should be treated as a weaker recovery-style control. Since the email account may be the same identity already trusted through SSO, it doesn’t provide much independence. Avoid relying on it alone for the most sensitive operations, and protect it with expiration, attempt limits, replay prevention, and clear audit logging.
Don’t create a second application password just for SSO users. It adds another credential system to secure and maintain, and undermines the single-source-of-authentication model. Security questions are also weak for high-impact actions because answers can often be guessed, researched, or reused.
Use an identity-provider step-up flow when possible. With Google, request a fresh authentication using parameters such as `prompt=login` or an appropriate `max_age`, then verify the returned token’s `auth_time` so you know the authentication happened recently rather than merely reusing an existing session. The exact behavior depends on the provider and account configuration, so treat this as a recent-authentication check, not automatically as MFA.
For especially sensitive operations, MFA or WebAuthn is a stronger option than simply asking the identity provider to authenticate again. You can model the action as requiring a higher authentication assurance level or use an OAuth step-up challenge where the provider supports it. Ideally, make the elevated authentication short-lived and scoped to the specific action.
The important distinction is what threat you’re addressing. Recent authentication helps if someone gained access to an unattended session, while MFA or a security key helps more if the existing session or password has been compromised.
That makes sense. Checking the authentication time is especially useful because it distinguishes a genuinely recent sign-in from a silent session reuse.