Unexpected 5xx error code when accessing "/auth/v1/oauth/token"

[Kroppeb]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

I am trying to debug an issue I have been having an came across this bug which has caused the underlying issue to be obfuscated it seems.

I am triggering this line (I think, it's the error message that gets logged in the Supabase logs)

auth/internal/tokens/service.go

Line 700 in 2d3dbc6

return "", fmt.Errorf("HS256 is not supported for ID token signing")

This error then gets converted into a InternalServerError here:

auth/internal/api/oauthserver/handlers.go

Lines 449 to 458 in 2d3dbc6

	idToken, err := tokenService.GenerateIDToken(tokens.GenerateIDTokenParams{
	User: user,
	ClientID: client.ID,
	Nonce: nonce,
	AuthTime: user.LastSignInAt,
	Scopes: scopeList,
	})
	if err != nil {
	return apierrors.NewInternalServerError("Error generating ID token").WithInternalError(err)
	}

Resulting in a 5xx error code instead of an expected 4xx error code.

The software I'm using will retry when seeing a 5xx error. But given that the error was produced after the token was destroyed (as they are single use) this then results in a 403 error with "invalid_grant" "Invalid authorization code".

To Reproduce

Given the line I assume you can repro this by using HS256 signing. I can't actually give a setup that triggers this as I have a dev and a prod setup and although they have the same settings as far as I can see. One setup is running in this problem, while the other isn't.

[Kroppeb]

Just in case someone comes across this while debugging their application. The reason a request with HS256 was made is due to the lack of keys in the /auth/v1/.well-known/jwks.json endpoint. This happens if you haven't migrated to the JWT signing keys. This can be done in Settings > JWT Keys if you are using Supabase webclient.

Note that this endpoint is cached for 10 minutes. To see if the migration worked sooner is to add query parameters to your request. Eg ?foo=bar and see the updated value. Your real application will most likely have wait a bit.

Edit: this was not sufficient to get my application to not request HS256

[Kroppeb]

Also related:

auth/internal/api/jwks.go

Line 87 in 2d3dbc6

IDTokenSigningAlgValuesSupported: []string{"RS256", "HS256", "ES256"}, // TODO :: should create this based on signing key config?

This is saying HS256 is supported even when it isn't.