Client JwtBearer grant type should support non Jwt principal

[sclorng]

Expected Behavior

Given a client registration with authorization-grant-type: urn:ietf:params:oauth:grant-type:jwt-bearer and an arbitrary authentication, an implementation of OAuth2AuthorizedClientProvider should build a Jwt bearer with claim sub =authentication.getName(), sign it the same way Jwt Bearer client authentication does and use it as the assertion of the JwtBearer grant request.

It should be as simple as

Authentication authentication = new MyAuthentication(new MyPrincipal("john"));
String body = webClient
    .get()
    .attributes(authentication(authentication).andThen(clientRegistrationId("client-jwt-bearer")))
    .retrieve()
    .bodyToMono(String.class)
    .block();

Current Behavior

JwtBearerOAuth2AuthorizedClientProvider works only if the given authentication principal is a Jwt.
Which means when using this grant type, we must add a lot of code (which is for a most part the same as building the Jwt Bearer client assertion.

ClientRegistration clientRegistration = ...;
JWK jwk = jwkResolver.apply(clientRegistration);
NimbusJwsEncoder jwsEncoder = new NimbusJwsEncoder(new ImmutableJWKSet<>(new JWKSet(jwk)));
JoseHeader joseHeader = ...;
JwtClaimsSet.Builder claimsBuilder = JwtClaimsSet.builder()
  .issuer(clientRegistration.getClientId())
  .subject("john")
  .audience(Collections.singletonList(clientRegistration.getProviderDetails().getIssuerUri())) // audience is the issuer uri
  .id(UUID.randomUUID().toString())
  .issuedAt(issuedAt)
  .expiresAt(expiresAt);
JwtClaimsSet jwtClaimsSet = claimsBuilder.build();
Jwt jws = jwsEncoder.encode(joseHeader, jwtClaimsSet);

Authentication authentication = new JwtAuthenticationToken(jws);
String body = webClient
    .get()
    .attributes(authentication(authentication).andThen(clientRegistrationId("client-jwt-bearer")))
    .retrieve()
    .bodyToMono(String.class)
    .block();

Is it the way we should use it ?

Context

JwtBearer grant type is not for exchanging the request bearer token but to allow a client to build/sign an Assertion of type Jwt with a subject specified by the client.

[jgrandja]

@scrocquesel

JwtBearer grant type is not for exchanging the request bearer token but to allow a client to build/sign an Assertion of type Jwt with a subject specified by the client.

This is not correct. The JwtBearer grant type IS for exchanging the request bearer token. It is NOT used to build/sign an Assertion of type Jwt. It seems you are referring to gh-8175?

Please review the spec in Section 2.1. Using JWTs as Authorization Grants.

I'll close this as invalid as JwtBearerOAuth2AuthorizedClientProvider and associated DefaultJwtBearerTokenResponseClient has been implemented correctly as per spec.

[sclorng]

Read section 3.3 about audience. Then, you will understand that it cannot work.

The JWT MUST contain an "aud" (audience) claim containing a
value that identifies the authorization server as an intended
audience.

But, the token provided in as a bearer in a request to a service MUST contain an audience claim containing a value that identifies the service as an intended audience.
It is not common to have a token emit to access a service to have an audience of the authorization server as it is not the purpose of such a token.
Which means that, ultimately, the JWT will be build and signed by the client with such a claim value and issuer claim will be the client id (or the client will need to request a token with such an audience value to another service.) as described in Section 3 of the spec. See https://datatracker.ietf.org/doc/html/rfc7521#section-3

What you describe is the rfc8693 with a subject_token_type of urn:ietf:params:oauth:token-type:access_token

See OAuth 2.0 Token Exchange

urn:ietf:params:oauth:token-type:access_token
Indicates that the token is an OAuth 2.0 access token issued by
the given authorization server.

[sclorng]

Although this document does not define the processes by which the
client obtains the assertion (prior to sending it to the
authorization server), there are two common patterns described below.

I think a good way to be compliant with the spec would be to add a Converter<OAuth2AuthorizationContext, Jwt> to the JwtBearerOAuth2AuthorizedClientProvider.
That way, the implementation will not drive the way the JWT is obtained. Default implementations could be :

• use the principal if its a JWT and documentation should clearly states that the token shoud not be the Authorization: Bearer token received in the current request. It will allow to easily drop in a Jwt obtained from another STS and keep the current behavior.
• use the current principal name to build/and sign a JWT issued by the client itself. This one could use something similar to the NimbusJwtClientAuthenticationParametersConverter to allow to resolve the JWK used to sign as it the exact same needs.

[jgrandja]

@scrocquesel

The JWT MUST contain an "aud" (audience) claim containing a
value that identifies the authorization server as an intended
audience.

But, the token provided in as a bearer in a request to a service MUST contain an audience claim containing a value that identifies the service as an intended audience.

The point you reference (Section 3 - No.3) is referring to Client Authentication processing NOT Authorization Grant processing.

Below is the full spec:

The JWT MUST contain an "aud" (audience) claim containing a
value that identifies the authorization server as an intended
audience. The token endpoint URL of the authorization server
MAY be used as a value for an "aud" element to identify the
authorization server as an intended audience of the JWT. The
authorization server MUST reject any JWT that does not contain
its own identity as the intended audience.

Take note of the bold highlight. This clearly indicates that the aud of the assertion is the Authorization Server's token endpoint URL, which is used for client authentication. It further states..." the authorization server MUST reject any JWT that does not contain its own identity as the intended audience", which further validates that this spec is for Client Authentication processing.

FYI, the current implementation has been tested and works to spec. Please see this comment.

use the current principal name to build/and sign a JWT issued by the client itself.

Where exactly in the spec does it state that this behaviour should be implemented? This applies to Client Authentication only and does not apply to Authorization Grant processing. If you believe it does, please refer me to the section in the spec that states this.

At this point, if you still feel the current implementation is incorrect, please provide a minimal reproducible example with the provider you're using to integrate this feature with. Also provide a link to the reference of the provider's documentation for urn:ietf:params:oauth:grant-type:jwt-bearer.

[sclorng]

You exactly point out the problem in the bold section :

The
authorization server MUST reject any JWT that does not contain
its own identity as the intended audience.

This is exaclty the issue I have when reusing the bearer token given to the service which audience is the service resource id.

Find out a sample use case of this grant flow : https://developer.atlassian.com/cloud/jira/software/user-impersonation-for-connect-apps/

See some implementation https://curity.io/resources/learn/jwt-assertion/#user-authentication-using-jwts

These checks are like JWTs used for client authentication. In particular, the JWT must contain an audience (aud) claim. The value must be the OAuth profile’s token endpoint.

Note that the issue you refer to state that it doesn't work due to missing requirement (aud claim value is not good) #6053 (comment)

Note also that the spec says

Authentication of the client is optional, as described in
Section 3.2.1 of OAuth 2.0 [RFC6749], and consequently, the
"client_id" is only needed when a form of client authentication that
relies on the parameter is used.

Rephrased this states that the assertion is by itself sufficient to authenticate the client as it is signed by it.

Is is sufficient to reconsider ?

[jgrandja]

@scrocquesel I did not receive a response to:

Where exactly in the spec does it state that this behaviour should be implemented? ... please refer me to the section in the spec that states this.

Both Atlassian and Curity specify what the claims should be in the Jwt assertion for the jwt-bearer grant flow. These are specific to these providers and don't necessarily port to other providers, as the spec does not detail what the claims should be in a jwt-bearer authorization grant. It ONLY details what the claims should be in a Jwt assertion for Client Authentication. Our main priority is to implement to spec and non-standard behaviour is the responsibility of the application.

The JwtBearerOAuth2AuthorizedClientProvider is a basic implementation of the jwt-bearer authorization grant type and it's designed with this intent. All it needs is a Jwt as input. It is not designed (or intended) to create a Jwt from other inputs, as it would complicate the implementation and no where in the spec it states that this behaviour must be implemented.

The part that you are missing with the Atlassian integration is "2. JWT token exchange: The app creates an assertion...". Please add your requirements (or vote) in the JwtEncoder PR #9208 as this is what you need to create your Jwt assertion. Then you could easily create any instance of Authentication that returns the created Jwt via Authentication.getPrincipal() and ensure OAuth2AuthorizationContext.getPrincipal() returns this Authentication you need to create.