Token Introspection fails if issuer claim is not a URI

[MatthiasDrewsCS]

Describe the bug
The token introspection endpoint fails, if the passed token contains an issuer claim, which is not a URI.

Looking at the specification in https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.1, it says that it must be an URI or String. In our specific case it is not a URI, because we set the issuer to String as we are following the client assertion specification (https://datatracker.ietf.org/doc/html/rfc7521), so the issuer claim is the clientId.

The stacktrace is:

java.lang.IllegalArgumentException: iss must be a valid URL
	at org.springframework.security.oauth2.server.authorization.OAuth2TokenIntrospection$Builder.validateURL(OAuth2TokenIntrospection.java:337)
	at org.springframework.security.oauth2.server.authorization.OAuth2TokenIntrospection$Builder.validate(OAuth2TokenIntrospection.java:307)
	at org.springframework.security.oauth2.server.authorization.OAuth2TokenIntrospection$Builder.build(OAuth2TokenIntrospection.java:278)
	at org.springframework.security.oauth2.server.authorization.authentication.OAuth2TokenIntrospectionAuthenticationProvider.withActiveTokenClaims(OAuth2TokenIntrospectionAuthenticationProvider.java:158)
	at org.springframework.security.oauth2.server.authorization.authentication.OAuth2TokenIntrospectionAuthenticationProvider.authenticate(OAuth2TokenIntrospectionAuthenticationProvider.java:114)
	at org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:182)
...

Expected behavior
Using the introspection token endpoint should be possible if the issuer claim is not a URI. I don't see why the claims are validated in the introspection endpoint in such a way, that tokens which have been created just before are invalid

[ramesh-nair-dev]

Hey Matt
Please review my changes

[jgrandja]

@MatthiasDrewsCS

RFC 7519 JSON Web Token (JWT) is a generalized specification that other specifications MAY comply to in full or part.

The iss claim in the OAuth 2.0 Token Introspection response states:

String representing the issuer of this token, as defined in JWT [RFC7519]

The iss claim in JSON Web Token (JWT) states:

The "iss" (issuer) claim identifies the principal that issued the
JWT. The processing of this claim is generally application specific.
The "iss" value is a case-sensitive string containing a StringOrURI
value.

Although it states that the case-sensitive string is a String or URI, the key words are "The processing of this claim is generally application specific.".

Given that the processing of the iss claim is performed by OAuth2TokenIntrospectionAuthenticationProvider via the authorization servers OAuth2TokenIntrospectionEndpointFilter, the iss claim is a URL since the authorization server minted the access token. See Authorization Server Metadata:

issuer
REQUIRED. The authorization server's issuer identifier, which is
a URL that uses the "https" scheme and has no query or fragment
components.

As far as your use case goes:

In our specific case it is not a URI, because we set the issuer to String as we are following the client assertion specification (https://datatracker.ietf.org/doc/html/rfc7521), so the issuer claim is the clientId

This doesn't appear to be a valid use case for a Token Introspection request flow. An authorization server will return metadata of an access token (or refresh token) that itself minted and the iss claim MUST be a URL that identifies the authorization server.

Can you provide more details on your use case?

At this point, I don't see any issues with the current implementation so this likely will be closed.

[MatthiasDrewsCS]

Hi @jgrandja ,

thank you for your feedback!

To explain our use case a little bit:
Our implementation of the authorization server is able to create tokens, which are then used as credentials for another authorization server to get another token from there. This flow is described in https://datatracker.ietf.org/doc/html/rfc7521#section-3 (figure 1). So I am talking about these assertion tokens here. The iss claim is the client_id, which is used to identify the client at the other authorization server (https://datatracker.ietf.org/doc/html/rfc7521#section-5.2)

This works perfectly fine, as we registered our own instance of an OAuth2TokenCustomizer, which sets the iss claim to the required value.

Now that we are able to use the Spring Authorization Server for this use case to create tokens via the token endpoint, and also revoke them via the revocation endpoint, we were a bit surprised that the introspection endpoint fails. IMHO it would just be consequent to use the introspection endpoint with tokens, which have just been created before by the same authorization server

[jgrandja]

@MatthiasDrewsCS

So I am talking about these assertion tokens here

Are you using the assertion for Client Authentication or Authorization Grant ?

we are able to use the Spring Authorization Server for this use case to create tokens via the token endpoint

Please provide more details on the request flow. Is this where you are passing the assertion? What does the access token contain that is returned? What's the iss claim?

[MatthiasDrewsCS]

@jgrandja we are using it for client authentication to another authorization server.

The flow is actually liked described for example here: https://docs.secureauth.com/ciam/en/private-key-jwt-client-authentication.html. With the addition, that our authorization server does not act directly as a client to the other authorization server, but instead returns the assertion token to its client, using the token endpoint.

[jgrandja]

@MatthiasDrewsCS

our authorization server does not act directly as a client to the other authorization server, but instead returns the assertion token to its client, using the token endpoint

This flow is not valid as per spec. The client_assertion used for ClientAuthenticationMethod.PRIVATE_KEY_JWT is generated by the client NOT the authorization server. Furthermore, the client_assertion returned from the token endpoint is not valid. That explains why the iss is changed from the authorization server issuer identifier (URL) to the client_id (String). This is not correct either because the client_assertion is signed by the authorization server key, when it must be signed by the client's key.

Take a look at this integration test:

spring-authorization-server/oauth2-authorization-server/src/test/java/org/springframework/security/oauth2/server/authorization/config/annotation/web/configurers/OidcClientRegistrationTests.java

Line 244 in ded91ea

public void requestWhenClientRegistrationRequestAuthorizedThenClientRegistrationResponse() throws Exception {

specifically, registerClient() to see how a client generates a signed client_assertion and uses it to authenticate with the authorization server

spring-authorization-server/oauth2-authorization-server/src/test/java/org/springframework/security/oauth2/server/authorization/config/annotation/web/configurers/OidcClientRegistrationTests.java

Line 547 in ded91ea

private OidcClientRegistration registerClient(OidcClientRegistration clientRegistration) throws Exception {

As mentioned in this comment, the current implementation of Token Introspection endpoint is correct so I'll close this issue and associated PR.