What’s the best way to confirm sensitive actions for SSO users without local passwords?

I would not add a local password just for SSO users. A reasonable order of preference is recent identity-provider authentication, provider-managed MFA or WebAuthn, and then a carefully implemented one-time code as a fallback. Requiring confirmation only for clearly defined high-impact actions also makes the security model easier to explain and reduces unnecessary interruptions.

MFA is generally best handled by the identity provider rather than implemented separately in every application. For especially sensitive operations, use a step-up flow that requests stronger authentication or a recent authentication event. Standards such as OAuth step-up authentication can help structure this. The right design also depends on the threat you are addressing—account takeover, an unattended unlocked session, or accidental destructive actions may each call for different controls.

Use identity-provider step-up authentication when possible. For Google, an authorization request can use parameters such as `prompt=login` or an appropriate `max_age` value, then the application should inspect the returned authentication time and require that it is recent. That helps distinguish a genuinely recent authentication from simply reusing an old application session. Avoid creating a separate application password, since it introduces another credential system to maintain and undermines the single sign-on model.

If provider step-up authentication is unavailable or would make the experience too disruptive, a short-lived email OTP can be a practical fallback for destructive actions. It is common and relatively easy for users to understand, but it should be treated as weaker assurance because access to the email account may be linked to the same SSO identity. Use a short expiration, limit attempts, record the event, and never use security questions as the primary protection for high-risk actions.