IssueTracker

Generated Metadata

• Summary: The prompt=login parameter in Google's OIDC implementation isn't forcing re-authentication as per the OIDC specification. This feature request is to implement the re-authentication prompt to enhance security, especially in environments like K12 where unauthorized access is a concern.
• Tags:
  • oidc
  • prompt-parameter
  • sso
  • authentication
  • security

Additional resources:

• https://developers.google.com/workspace/add.../connect-third-party-service
• https://developers.google.com/workspace/guides/configure-oauth-consent
• https://developers.google.com/apps-script/concepts/scopes
• https://stackoverflow.com/questions/tagged/google-workspace?tab...6
• https://developers.google.com/apps-script/api/how-tos/enable

You can subscribe to this issue by clicking the star ⭐ button.

As I've shared this with peers I've realized I probably should have categorized this as a bug. My bad.

In my understanding, while the OIDC spec dictates behaviors for a given prompt value, those requirements are conditional on that prompt being supported by the authorization server.

Looking for a better component for this issue, but not finding one. This search, open issues with "prompt=login" returns just this request.

I agree, I couldn't find a better place for this. It's also annoying that openid.net seems to be down with a 503 today, but you can still view the link above on the wayback machine at https://web.archive.org/web/20250221105836/https://openid.net/specs/openid-connect-core-1_0.html, where it reads:

The Authorization Server SHOULD prompt the End-User for reauthentication. If it cannot reauthenticate the End-User, it MUST return an error, typically login_required.

Reading MUST and SHOULD according to RFC2119 (https://datatracker.ietf.org/doc/html/rfc2119), which is what is used by OIDC, seems to indicate that in any situation where the identity provider can reauthenticate the user, it needs to. The only case when the authorization server could choose not to force a reauth would be in instances where it is not possible (such as with service accounts or something like that) - but that should be as a last resort, and still has to throw an error.

In any case, the former behavior is certainly preferable, as I described in the Impact section. Microsoft SSO, for example, does implement this functionality, and some of our customers have thought about a switch to Microsoft-based products purely over this concern.