I can't get Authorization: Bearer <token> to work with version 6.1.1 . It works with 5.1.1

[ieugen]

I've tried for several hours to make it work without success.

I've used it with keycloak provider and oidc provider.
I've tested with echoserver to see the Authorization: Bearer <> header and no luck.
I think it's broken.

I am working to configure authentication for kubernetes dashboard.

extraArgs:
  provider: 'oidc'
  upstream: http://echoserver.default
  pass-authorization-header: true
  pass-basic-auth: false
  skip-jwt-bearer-tokens: true
  ssl-upstream-insecure-skip-verify: true
  email-domain: '*'
  skip-provider-button: true
  oidc-issuer-url: "https://REDACTED/auth/realms/gpi-infra"
  login-url: "https://REDACTED/auth/realms/gpi-infra/protocol/openid-connect/auth"
  redeem-url: "https://REDACTED/realms/gpi-infra/protocol/openid-connect/token"
  validate-url: "https://REDACTED/auth/realms/gpi-infra/protocol/openid-connect/userinfo"

[NickMeves]

Hmmm, 6.1.1 is working fine for me with bearer headers.

Some things I potentially see missing in your configuration that might be the source of your issue:

Even though you don't use it (since you want bearer header auth). cookie_secret is a required parameter. I believe the server won't start if you don't have a valid one set. You also have oidc set as your provider, so client_secret is also required (even though the mode you are about to use does use that either if you are getting IDTokens out of band). You can set both of those to dummy values.

You'll need a client_id that matches the audience claim of your token. In bearer header mode with the oidc provider, the code will first get a valid JWKS to validate your token from you oidc-issuer-url .well-known/openid-configuration or .well-known/jwks.json. Then it will verify your JWT against the appropriate JWKS (the single one in your case) based on the issuer+audience pair. Those being valid is a requirement of the upstream OIDC library's IDToken verify method if I recall.

Hopefully that helps -- I can't fully visualize your architecture or how you get the IDToken you send in the bearer header, but those are the settings I use to send IDTokens in bearer headers.

[ieugen]

Hi,

Thannks for looking into this. I did pass client and cookie secret via kubernetes secrets

I did not realize this was not clear.
Like I mentioned it works with version 5 almost unchanged.
When i get back I will see if I can post the full yaml deployment.

I ran in the same issue using oidc as a provider. IdP is an internal hosted keycloak instance.

You'll need a client_id that matches the audience claim of your token.

Do you refer to the id or access token?

Once I try to send a previously retrieved access or ID token as "Authorization: Bearer $token" I get:
The client ID created is "iap".
[2020/09/23 10:28:58] [oauthproxy.go:871] Error loading cookied session: Cookie "iap" not present ::1 - - [2020/09/23 10:28:58] localhost:8081 GET - "/" HTTP/1.1 "python-requests/2.24.0" 403 2621 0.000
The response is the "Sign-in" login page and not dispatching to the upstream.

The access token has the following aud set:
"aud": [ "iap, "broker", "account" ]

The ID token has the following aud set:
"aud": "iap"

[ghellings]

I'm having basically the same problem. Config works in v6.0.0 and doesn't after v6.1.0.

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: oauth2-proxy
  name: oauth2-proxy
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app: oauth2-proxy
  template:
    metadata:
      labels:
        k8s-app: oauth2-proxy
    spec:
      containers:
      - args:
        - --client-id=REDACTED
        - --client-secret=REDACTED
        - --cookie-secure=false
        - --provider=google
        - --email-domain=*
        - --upstream=file:///dev/null
        - --http-address=0.0.0.0:4180
        - --cookie-refresh=1h
        - --skip-jwt-bearer-tokens=true
        - --request-logging=true
        - --auth-logging=true
        - --standard-logging=true
        - --redirect-url=https://REDACTED/oauth2/callback
        - --oidc-issuer-url=https://accounts.google.com
        - --pass-authorization-header=true
        - --whitelist-domain=.REDACTED

        env:
        - name: OAUTH2_PROXY_CLIENT_ID
          value: REDACTED.apps.googleusercontent.com
        - name: OAUTH2_PROXY_CLIENT_SECRET
          value: REDACTED
        - name: OAUTH2_PROXY_COOKIE_SECRET
          value: REDACTED
        image: quay.io/oauth2-proxy/oauth2-proxy:v6.0.0
        imagePullPolicy: Always
        name: oauth2-proxy
        ports:
        - containerPort: 4180
          protocol: TCP

V6.1.0 and above give me the following output, while v6.0.0 to v5.1.0 work

2020/09/30 22:54:41] [logger.go:488] mapping path "/dev/null" => file system "/dev/null"
[2020/09/30 22:54:41] [logger.go:488] Skipping JWT tokens from configured OIDC issuer: "https://accounts.google.com"
[2020/09/30 22:54:41] [logger.go:488] OAuthProxy configured for Google Client ID: REDACTED.apps.googleusercontent.com
[2020/09/30 22:54:41] [logger.go:488] Cookie settings: name:_oauth2_proxy secure(https):false httponly:true expiry:168h0m0s domains: path:/ samesite: refresh:after 1h0m0s
[2020/09/30 22:54:41] [logger.go:488] HTTP: listening on 0.0.0.0:4180
[2020/09/30 22:54:49] [logger.go:506] Error retrieving session from token in Authorization header: not implemented
[2020/09/30 22:54:49] [logger.go:506] Error loading cookied session: cookie "_oauth2_proxy" not present, removing session
100.119.128.9:33638 - - [2020/09/30 22:54:49] REDACTED GET - "/oauth2/auth" HTTP/1.1 "Ruby" 401 21 0.012

[NickMeves]

Hmmm - there might be odd interactions with non-oidc providers (you have google set). It was the only Provider where the contributer implemented the CreateSessionStateFromBearerToken.

I'll need to dig, I believe that is ahead in the middleware chain before the generic extra JWT handlers (that assume OIDC and look for .well-known/openid-configuration). I don't fully know what the Google provider did with tokens in a bearer session pre-v6 (I'm not a google provider user)

Thanks for the details!

[knordum]

Can also confirm I'm seeing the same issue where provider=keycloak.
Version 5.1.0 - 6.0.0 works ok, but version 6.1.1 gives error: Error retrieving session from token in Authorization header: not implemented

[NickMeves]

I have a theory what's happening:

Because keycloak also uses some of the OIDC parameters, it goes down this codepath:

oauth2-proxy/pkg/validation/options.go

Line 78 in 4a54c94

if o.OIDCIssuerURL != "" {

This results in SetOIDCVerifier being called (which makes the first extra-jwt issuer the provider instead of the generic extras):

oauth2-proxy/pkg/validation/options.go

Line 145 in 4a54c94

o.SetOIDCVerifier(provider.Verifier(&oidc.Config{

If that's the case, the first provider in the chain is Keycloak's CreateSessionStateFromBearerToken:

oauth2-proxy/oauthproxy.go

Line 237 in d9c141a

if opts.GetOIDCVerifier() != nil {

Which isn't implemented.

As a workaround you can set the OIDC details you want to use to validate your sessions --extra-jwt-issuers (if anything in the chain passes, auth is valid, so it will just move past the Not Implemented).

Long term, a Keycloak user will need to implement CreateSessionStateFromBearerToken and submit a PR. If Keycloak is close to OIDC - the implementation will likely mirror that Provider

oauth2-proxy/providers/provider_default.go

Line 120 in d9c141a

func (p *ProviderData) CreateSessionStateFromBearerToken(_ context.Context, _ string, _ *oidc.IDToken) (*sessions.SessionState, error) {

CC: @JoelSpeed - In case you have any other thoughts since you spearheaded the middlware auth chain refactor.

[NickMeves]

Long term I have this as a vision for Bearer auth to avoid issues like this: #835

[NickMeves]

I think the unifying point in all these cases is they have oidc-issuer-url + skip-jwt-bearer-tokens set on non OIDC providers that didn't implement the method (Google & Keycloak in the 2 submitted example bugs).