Looks like some tests are failing, could you try rebasing onto our master branch and see if that fixes the issue?

@brianv0 By the way, you did a great work. I tried it, it is perfect and -extra-jwt-issuers is very useful.

I tried this as well and it worked great. However, I'm using -provider=google (with client id specified in an environment variable if it matters), and I did have to explicitly add -extra-jwt-issuers=https://accounts.google.com=$OAUTH2_PROXY_CLIENT_ID rather than it automatically using my configured provider.

@meastman It seems the o.oidcVerifier is only defined when o.OIDCIssuerURL is defined with -oidc-issuer-url.
https://github.com/pusher/oauth2_proxy/blob/9470608c4ca9c2a3d9e153fc8cbd35d491954f5b/options.go#L167-L181

Try to add -oidc-issuer-url https://accounts.google.com instead of -extra-jwt-issuers=https://accounts.google.com=$OAUTH2_PROXY_CLIENT_ID

But maybe oidc should be automatically defined for google provider

Try to add -oidc-issuer-url https://accounts.google.com instead of -extra-jwt-issuers=https://accounts.google.com=$OAUTH2_PROXY_CLIENT_ID

👍 That worked great.

But maybe oidc should be automatically defined for google provider

Agreed. I just wanted to mention it so it could at least be considered.

I've been meaning to get back to this soon, I don't understand what the travis error was - it looks like it was transient.

I think it's the case that Google, Azure are both technically OIDC providers but under a different name. Since Google is sort of special it could be considered so you don't have to explicitly list it.

@brianv0 Have you had a chance to look into this PR? I'd love to get this merged to master and start securing my API endpoint with oauth2_proxy. This is a feature that many people have been waiting for for a long time. Let me know if you need help with testing it.

I've done a new round on this and also added some unit tests. @JoelSpeed if you wouldn't mind re-reviewing this?

Will this patch make it possible to authenticate using only a "bearer token" (JWT) from an Authorization header, e.g no cookies?

I built a custom image with this patch, but get Cookie "_oauth2_proxy" not present. Seems like it still requires cookies? I have added the proxy in front of an API and want to authenticate using the Authorization header and not rely on cookies for backend services.

Yes, do you have the proper flags set by chance? What Provider are you using?

I started adding some more complete tests to make sure I’m sane, but it seems fine to me.

Hi, I am using an OIDC provider (keycloak) and have set skip_jwt_bearer_tokens = true in the configuration for the API.

My setup is like this. I got an OAuth2 proxy setup protecting the frontend which basically follows the Nginx example in the README. But with an additional "location" for an "upstream" API (this is setup in k8s). This OAuth2 proxy is configured to "pass" the authorization header on a call to upstream (nginx). The idea was to have another OAuth2 proxy in front of the (nginx) upstream API and use a bearer token only validation. In order to ensure that the proxy in front of the API only authenticates using validation of the JWT I have explicitly removed the "oauth2" cookies issued by the frontend proxy before proxying traffic to the upstream API (I hope that explanation made sense).

I added what should be a more realistic test case for that in b3135e8, and it seems to be working just fine. I will be testing this out today on my own environment (it's been a little slow on this I need some other unrelated patches).

Okay I think addressed all the relevant issues and I did a rebase to pull in the new logging changes

This patch works for me, but only in "proxy" mode. I could not figure out why neither refresh tokens or JWT validation did not work in "auth_request" mode despite following suggested work arounds for header size limits, but it's indicative that the issue I had was outside the scope of this patch.

Ah okay, so this is something I didn’t touch. The Authorization headed is only forwarded on proxy requests, and includes the Bearer prefix. In auth_request mode, you get a X-Auth-Request-Token back, without the prefix. Presumably most people are fine with this because it’s easy to add the header from the upstream (oauth2_proxy response):

auth_request_set $auth_token $upstream_http_x_auth_request_token;       
proxy_set_header Authorization "Bearer $auth_token";

I would note that this is useful when other backends also expect some kind of header.

I could add code to return the authorization header too, I will have to look and see if there was a reason why they didn’t do that originally though.

The Authorization headed is only forwarded on proxy requests, and includes the Bearer prefix.

Just to chip in here as I authored the Authorization header stuff; If you set -pass-authorization-header then you get the Authorization: Bearer <token> header on requests to proxied services; If you set -set-authorization-header then it should be set on the response headers so will be available in the Nginx auth_request mode.
https://github.com/pusher/oauth2_proxy/blob/8519e7ccae466bac8722411cc7cf43ef7bd6f56e/oauthproxy.go#L934-L936

@brianv0 Can you update for the conflict ?
@JoelSpeed Will it be possible to merge this after the conflict resolution ?

@JoelSpeed - I added an extra check to always validate the groups, if possible, of the token, based on #141, in bd651df.

It's not clear to me if this check will actually ever be executed - only the Google provider does a group check and I'm not sure if there's an easy way to get a bearer token from Google in any case, but I figured it might be surprising if that was the case.

(PS - this shows a change is requested, but I believe the previous changes were already applied)