Does oidc-client support jwt-bearer as an authorization grant type for azure workload identity?

[Sopka]

Consider the following setup:

The quarkus application is running in an azure kubernetes cluster and is registered with the azure oidc provider (EntraID). The pod in which the application runs is configured to use azure workload identity.

As a result the kubernetes cluster "injects" a JWT token into the pod, available at a specific filesystem path /var/run/secrets/azure/tokens/azure-identity-token.

This JWT token can be used instead of the usual client-secret to authenticate the client/application against the oidc provider to get an access token (RTF-7523, Section 2.2)
The request to obtain a valid access_token from the oidc using the injected jwt as an assertion parameter instead of the client_secret is documented here: Access token request with a federated credential

The injected token is only valid for a short period of time (default 1h) and only available inside the kubernetes cluster. This increases security, because there is no need to configure a static client secret anymore.

One way would be to implement a simple custom client request filter to exchange the token, check for expiration, handle caching...

But the whole process looks so similar to what has already been implemented for the oidc client filter documented here: Quarkus OIDC Supported Token Grants. But the static properties configuration is not enough, because the token is dynamic and must be read from the file-system again after expiration.

Any ideas how to re-use the existing oidc client filter implementations in this case?

[quarkus-bot[bot]]

/cc @geoand (kubernetes), @iocanel (kubernetes), @pedroigor (bearer-token,oidc), @sberyozkin (bearer-token,jwt,oidc)

[sberyozkin]

@martaisty Please watch #40013 in case you need it for quarkus-oidc, if that is implemented the way it is suggested then it will work for both quarkus-oidc-client and quarkus-oidc. But as I said, if you do use quarkus-oidc-client then you can do it right now as shown in the #38541 test filter

[martaisty]

Thank you for your answers @sberyozkin Indeed, that was what I needed. By providing client_id and client_assertion I was able to get it up and running for quarkus-oidc-client exactly how it was required (https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-client-creds-grant-flow#third-case-access-token-request-with-a-federated-credential). By the way, don't know why client_id wasn't picked up from quarkus.oidc-client.client-id, though quarkus.oidc-client.scopes was 🤷
I was just thinking about a more plug-and-play way, something like providing a path to the token, like quarkus.oidc-client.credentials.jwt.path and using @OidcClientFilter, but making own OIdc Client Request Filter is good enough 👍

[martaisty]

Speaking of quarkus-oidc... Yes @sberyozkin , I would like to have it as a part of the authorization code flow. I don't use quarkus-oidc-client to do it myself. I have two different use cases:

1. Service to service call (one service calls another one on behalf of itself) This one was solved by creating custom Oidc Client Request Filter ✔️
2. Web app calls API on behalf of user. During the authorization code flow a web app gets access token for further propagation to the API. This one is still unresolved, will continue discussion on this at Support JWT bearer client authentication for quarkus-oidc #40013

[sberyozkin]

@martaisty Thanks for testing with quarkus-oidc-client.

By the way, don't know why client_id wasn't picked up from quarkus.oidc-client.client-id, though quarkus.oidc-client.scopes was

I think it is redundant, and probably a doc issue, since you are authenticating the client using a JWT bearer token. It probably has the client id as one of its claims. This is why it is currently coded not to incl the client id if you use this form of the client authentication. The fact it works without the client id being passed explicitly for you confirms it is not necessary in this case.

I was just thinking about a more plug-and-play way, something like providing a path to the token, like quarkus.oidc-client.credentials.jwt.path and using @OidcClientFilter, but making own OIdc Client Request Filter is good enough 👍

Right this is actually the plan, you'd do something like

@Endpoint.Type=Token
public client MyFilter implements OidcRequestFilter {
     void filter(..., OidcRequestContextProperties props) {
            props.set("client_assertion", "1234");
     }
}

and it will work for both OIDC client and OIDC extensions. It will require recalculating the buffer but the grant requests are typically short sequences, so it will be cheap. May be some other optimizations can be done

[martaisty]

The fact it works without the client id being passed explicitly for you confirms it is not necessary in this case.

@sberyozkin It doesn't work without client id passed explicitly, as I mentioned I provided client_id explicitly through additional parameters