[Feature]: JWT validation only mode about oauth2-proxy HOT 8 OPEN

Sorry for the advertising, for this challenge I have published this tool. You might want to fork it and rebuild it locally
https://github.com/matzegebbe/web-jwks-validator

from oauth2-proxy.

Hi @jkroepke, can you put an example of token that you want to validate?
I'm asking this because if you want to validate a token that follow the standard described in the page ServiceAccount token volume projection, I think that if and only if k8s sign the token (it's not visible in the example and I don't have any cluster to try it now) this is theorically already working with some tricks in the configs.

The idea is that you set the client-id value as the same of the audience of the token ("aud" claim), disable the login page, activate the function to check bearer token and put a random value as client-secret(this will never be used).

Let me know if this was helpful or not 😄

from oauth2-proxy.

Hey @CesarStef

thanks for your detailed answers.

Yes, I want to valid JWT issued by Service Account and secondly I also want to validate tokens issued by Entra ID that are coming trough Managed Identity (like AWS Instance Roles, but the token is an OIDC compatible JWT), Ref: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http

In case you are not familiar with Azure Managed Identity, you can assume its the same concept as Kubernetes Service Accounts, but only for Virtual Machines and the token is available via http.

The only difference here is that the aud claim is not fully free to choice. In the case, the audience claim must be pre-registered on the Entra ID first.

Additionally, I also would like to authenticate JWT tokens from different sources. While I'm fully flexible at Kubernetes side, for Entra ID I have to use the same audience claim at Entra ID side.

I'm also missing the client ID verification.

The idea is that you set the client-id value as the same of the audience of the token ("aud" claim)

But not secure! The audience value at the ServiceAccount token volume projection is not validated. Any user could create a service account token with the "correct" audience value to successfully validate against oauth2-proxy.

from oauth2-proxy.

Hi @jkroepke,

Sorry for the late response!

But not secure! The audience value at the ServiceAccount token volume projection is not validated. Any user could create a service account token with the "correct" audience value to successfully validate against oauth2-proxy.

The audience check is only a part of all the process to validate a token.

In my previous message I putted a condition as necessary to make the validation work:

I think that if and only if k8s sign the token (it's not visible in the example and I don't have any cluster to try it now) this is theorically already working with some tricks in the configs.

Attackers can't simply put a valid clientId in the token because oauth2-proxy need to verify that the signature of the token is really made by the correct issuer.
Every IdP use their private key to sign their access token and give you an endpoint to find their public key to verify that a token is really issued by them.

If somebody manipulate the token, the signature just change and the token is invaid.

oauth2-proxy (at least for the oidc standard provider) follow the standard and checks three things to validate the token:

1. The iss claim (issuer) must be the correct one
2. The aud claim must contain the clientID (you can change the claim to check)
3. The signature is really made by the issuer

Additionally, I also would like to authenticate JWT tokens from different sources.

As I know this can't be done now but there are some PR in working to make this possible (maybe some of maintainers can help more then me on this point).

from oauth2-proxy.

Attackers can't simply put a valid clientId in the token because oauth2-proxy need to verify that the signature of the token is really made by the correct issuer.
Every IdP use their private key to sign their access token and give you an endpoint to find their public key to verify that a token is really issued by them.

This is true, but audience is a free-text value field at kubernetes. On kubernetes, you get signed a token with any aud value of your choice.

For example:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /var/run/secrets/tokens
      name: vault-token
  serviceAccountName: build-robot
  volumes:
  - name: vault-token
    projected:
      sources:
      - serviceAccountToken:
          path: vault-token
          expirationSeconds: 7200
          audience: vault

In that case, the aud value is vault here. As I know, I can put any value of my choice here and it gets signed.

oidc standard provider

But Kubernetes isn't OIDC standard provider and doesn't want to be, maybe doesn't have to be.

In terms of OAuth2, the aud claim has a different purpose (https://www.rfc-editor.org/rfc/rfc7519#section-4.1.3)

The "aud" (audience) claim identifies the recipients that the JWT is intended for.

That the reason, why the aud claim in Kubernetes and Entra ID is free to choice (Note: Not talking about end-user token, more token about identity (machine) tokens). For example in Entra ID, the aud claim must be https://management.azure.com/, if I want to use the token to authenticated against https://management.azure.com/ and has no link against the clientID

From OAuth2 point of view, there is link to the clientID.

Based on your comment, extra-jwt-issuers is designed for OIDC compatible provider and should not used for OAuth2 Providers, like Kubernetes.

A flag like extra-jwt-issuers, but using the sub claim instead the aud claim would be feasible solution.

from oauth2-proxy.