Impact

Under a very specific set of circumstances an attacker could use an OpenID Connect compliant ID token issuer in their control to authenticate as a legitimate user.

This would only be possible if the attacker used the POST /token?grant_type=id_token endpoint with a JSON body that:

• Has an unspecified or empty string provider
• A valid OIDC ID token issuer URL in issuer
• A valid client_id property for the issuer

Furthermore, the attacker would have to use this endpoint prior to a non-OIDC sign-up of the legitimate user being targeted.

Patches

The problem is patched since version 2.47.0. All OIDC issuers you trust must now be specified in the GOTRUE_EXTERNAL_ALLOWED_ID_TOKEN_ISSUERS environment variable.

For example, to use Firebase ID tokens you should use:

GOTRUE_EXTERNAL_ALLOWED_ID_TOKEN_ISSUERS=https://securetoken.google.com/<firebase-project-id>

You can specify multiple issuers with commas.

Projects using Supabase Auth will progressively receive this patch. Until then the vulnerable endpoint has been scoped down to allow three issuer groups:

• Sign in with Apple (appleid.apple.com)
• Sign in with Google (accounts.google.com)
• Sign in with Firebase (securetoken.google.com)

Please open a new support ticket if your project relies on another issuer.

Projects will be automatically configured with the GOTRUE_EXTERNAL_ALLOWED_ID_TOKEN_ISSUERS config value once the patched version is made available on all projects.

Workarounds

There are no workarounds to mitigate the issue. If you do not use OIDC ID tokens for sign-in in your self-hosted instance of GoTrue, you can block any requests to the POST /token endpoint only when grant_type is id_token in the query parameters.