Restrict id_token_hint to be an ID token at the logout endpoint

[thiva-k]

Description

GET/POST /oauth2/logout accepts any server-signed JWT as id_token_hint provided its issuer matches and its audience resolves to a registered client. There is no check that the token is actually an ID token.

An access token issued to an application with no configured default audience carries aud=client_id, since ResolveDefaultAudience falls back to the client id, so it satisfies both conditions. Expiry is intentionally not enforced for id_token_hint per OIDC RP-Initiated Logout, so an expired access token is accepted as well.

The sign-out flow suppresses the End-User confirmation whenever a hint is present, so a party holding any access token for the target client can suppress it. That confirmation is the mitigation for forced logout via cross-site navigation. Not currently exploitable because the default sign-out flow ships with promptOnSignOut: false, but it must be fixed before that mitigation is relied on.

Steps to Reproduce

1. Register a confidential client with the authorization_code grant and no defaultAudience on its access token config.
2. Complete an authorization code flow and keep the access_token.
3. Call GET /oauth2/logout?id_token_hint=<access_token>.
4. The request is accepted and the client resolves from the access token's aud. Setting promptOnSignOut: true on the sign-out flow's SessionSignOutExecutor node shows the confirmation is skipped, where a request with no hint would prompt.

Version

1.0.0

Environment Details (with versions)

No response

[Thareesha98]

@thiva-k I would like to pick this up, unless you are already on it.

Reading clientIDFromIDTokenHint in logout/service.go, it verifies the signature and issuer and then goes straight to audienceClientID, so nothing constrains the token type. The typ header looks like the cleanest discriminator we already have: BuildAccessToken writes at+jwt and BuildIDJAG writes oauth-id-jag+jwt, while BuildIDToken writes JWT, and GenerateJWT always sets the header. So accepting only JWT rejects the access token case in the report and ID-JAG assertions along with it.

One thing I want to check with you: refresh tokens are also built with typ: JWT, so the header alone does not separate them from ID tokens. They fail anyway a step later because their aud is the issuer rather than a client id, so it is not reachable today. I would still rather reject them explicitly than rely on that. Happy to go either way if you have a preference.

[Thareesha98]

@thiva-k opened #4992 for this.

On the refresh token question from my earlier comment: ValidateIDJAGSubjectToken already makes the same "must be an ID token" call for subject_token, and it pairs the typ header with an access_token_sub rejection. I followed that rather than adding a second convention, so refresh tokens are refused explicitly instead of only failing later on client resolution.

[thiva-k]

Hi @Thareesha98 ,

This issue is already being worked on. Could you please comment and get yourself assigned to issues before starting to work on them.

Thanks

[Thareesha98]

Apologies, that is my mistake. I commented first but then went ahead without waiting for the assignment, which is not the same thing, and on an issue filed ten minutes earlier I should have been more patient rather than less.

Happy to close #4992 if you are already on it, just say the word. If anything in it is useful, please take it. The one thing worth carrying over either way is that ValidateIDJAGSubjectToken already makes this exact "must be an ID token" call for subject_token, pairing the typ header check with an access_token_sub rejection, so the logout endpoint can reuse that rule rather than growing a second one.

I will wait to be assigned before starting on anything from now on.

[thiva-k]

Apologies, that is my mistake. I commented first but then went ahead without waiting for the assignment, which is not the same thing, and on an issue filed ten minutes earlier I should have been more patient rather than less.

Happy to close #4992 if you are already on it, just say the word. If anything in it is useful, please take it. The one thing worth carrying over either way is that ValidateIDJAGSubjectToken already makes this exact "must be an ID token" call for subject_token, pairing the typ header check with an access_token_sub rejection, so the logout endpoint can reuse that rule rather than growing a second one.

I will wait to be assigned before starting on anything from now on.

No issues and thanks for the input. You can go ahead and close the PR. Feel free to contribute to other issues.