Allow pass-through of valid JWT Bearer tokens with OpenID Connect/JWKS issuers about oauth2-proxy HOT 11 CLOSED

I've successfully used this with AWS Cognito (oidc provider) using the skip-jwt-bearer-tokens and the additional-jwt-issuers and wanted to give a big thumbs up to brianv0 for doing this work. This saved me a lot of pain and work because I can now use the proxy for both API calls and Web authentication.

from oauth2-proxy.

I'm currently testing the skip-jwt-bearer-tokens in conjunction with additional-jwt-issuers to validate jwt tokens requested externally from AzureAd. However, AzureAd has some limitations on the claims it sets in the tokens meaning that:

• email claim might not be set unless you are using office365 or you are syncing an on prem AD
• sub is some specific identifier that cant be used to map a user in a downstream application

It might be interesting to maybe have the GetJwtSession's claim extraction to be configurable via provider in the same way p.provider.GetEmailAddress(s) is, so that sub can be set from upn instead?

Is that something that would make sense?

from oauth2-proxy.

This is great, and like @bpatters I am using the skip-jwt-bearer-tokens and additional-jwt-issuers to achieve both API calls and web authentication with AWS Cognito (OIDC provider).

However, every time I wanted to add a new client that is used to make API calls (using client-creds flow), I have to add the new client to the addition-jwt-issuers flag, requiring the proxy to restart. In my use case, clients are created daily, and restarting proxy and updating the config (could end up quite long when 100s of clients are used) is not practical.

When using providers like Keycloak, I've worked around this by manipulating the client to include the correct aud for the target. However, with AWS Cognito, and other providers, this is not possible.

Does anyone have any suggestions on a workaround for this?

@lyndon160 hey, did you ever find a solution for this?

from oauth2-proxy.

Hey @brianv0, thanks for raising this PR.

In general I'm in favour of adding this feature but have a quick question about the use case.

In your implementation, you can provide a number of upstream issuers to allow tokens from, in the oauth2_proxy you can only normally have one upstream issuer, do you have a use case in mind in which you would want to have multiple upstream issuers for tokens?

My initial thoughts for adding this feature are that it would work only in conjunction with providers that are backed by OIDC (and therefore have a token verifier initialised already). We can then use the existing options client-id and oidc-issuer-url (or a known issuer like accounts.google.com) to allow tokens from the selected provider and re-use the internal token verifier that we already have.

This way we would either load the session from the cookie or from the header, then carry on with verification as normal (skipping session save for requests with bearer tokens). WDYT?

from oauth2-proxy.

In your implementation, you can provide a number of upstream issuers to allow tokens from, in the oauth2_proxy you can only normally have one upstream issuer, do you have a use case in mind in which you would want to have multiple upstream issuers for tokens?

Yes, the primary use case is actually that our OIDC provider (https://www.cilogon.org/oidc) issues ID tokens that expire fairly quickly - 15 minutes. But this is for securing a REST API which is effectively an interface to a batch system. When the batch job is finished, the user needs to upload results to a data store that's also protected with the same oauth2_proxy. So, internally, we decided we'd reissue new tokens ourselves (with a configured JWKS endpoint) - which we can guarantee to survive for the full lifecycle of the request. The alternative is passing around the original token, expired, but allowing it to be honored in any case since the request is originating from our network. Security didn't like the idea of that much. So, I wrote the code to work with both OpenID connect issuers and JWKS issuers.

In theory we could ask the client (typically python REST API stub or a GUI) to forward us the refresh token, in some cases the client will have the refresh token, but not in all cases.

Side note: I was thinking about that code yesterday, and it probably needs to use a map instead of just iterating through them all.

from oauth2-proxy.

My initial thoughts for adding this feature are that it would work only in conjunction with providers that are backed by OIDC (and therefore have a token verifier initialised already). We can then use the existing options client-id and oidc-issuer-url (or a known issuer like accounts.google.com) to allow tokens from the selected provider and re-use the internal token verifier that we already have.

This way we would either load the session from the cookie or from the header, then carry on with verification as normal (skipping session save for requests with bearer tokens). WDYT?

I realized reading this that maybe my flag should be something like additional-jwt-issuers or something, and if you add the skip-jwt-bearer-tokens it should automatically try to configure first with the internal token verifier we already have.

from oauth2-proxy.

I did a similar implementation to this a while ago for our own proof-of-concept purposes. See https://github.com/agentgonzo/oauth2_proxy/tree/bearer-tokens

Diff: bitly/oauth2_proxy@master...agentgonzo:bearer-tokens

from oauth2-proxy.

I realized reading this that maybe my flag should be something like additional-jwt-issuers or something, and if you add the skip-jwt-bearer-tokens it should automatically try to configure first with the internal token verifier we already have.

Let's go with this, do you have time to raise a PR @brianv0? The additional-jwt-issuers flag should only be used if the skip-jwt-bearer-tokens flag is true right?

from oauth2-proxy.

Yes and yes, I think I will be able to get to it sometime this week.

from oauth2-proxy.

This has been implemented and released, closing the issue now 😄

from oauth2-proxy.

This is great, and like @bpatters I am using the skip-jwt-bearer-tokens and additional-jwt-issuers to achieve both API calls and web authentication with AWS Cognito (OIDC provider).

However, every time I wanted to add a new client that is used to make API calls (using client-creds flow), I have to add the new client to the addition-jwt-issuers flag, requiring the proxy to restart. In my use case, clients are created daily, and restarting proxy and updating the config (could end up quite long when 100s of clients are used) is not practical.

When using providers like Keycloak, I've worked around this by manipulating the client to include the correct aud for the target. However, with AWS Cognito, and other providers, this is not possible.

Does anyone have any suggestions on a workaround for this?

from oauth2-proxy.