auth: Respect Bearer token authorization.

[tcolgate]

This patch will attempt to verify Authorization: Bearer tokens with providers. This is useful for proxying of API request.

We have an internal implementation of a provider that uses this to verify JWT tokens. I think that should be upstreamable , and useful to others.

[tcolgate]

Can try and add tests if desired.

[blardo]

Throwing my hat in the ring to say that this is a great feature improvement. I am currently trying to deploy a functioning single-point-of-entry app using oauth2_proxy with an nginx ingress controller, and being able to hand bearer tokens to the proxy rather than cookie auth is pretty much the last blocker.

[tcolgate]

Sorry for the lack of response. We use this with resigned Google service accounts which each come with as usable email

On Thu, 22 Feb 2018, 19:14 John Arnold, [email protected] wrote:

@johnarnold commented on this pull request.

In oauthproxy.go https://github.com/bitly/oauth2_proxy/pull/470#discussion_r170063219:

@@ -722,3 +734,15 @@ func (p *OAuthProxy) CheckBasicAuth(req *http.Request) (*providers.SessionState, } return nil, fmt.Errorf("%s not in HtpasswdFile", pair[0]) }

+func (p *OAuthProxy) CheckBearerAuth(value string) (*providers.SessionState, error) {

• email, err := p.provider.GetEmailAddress(&providers.SessionState{AccessToken: value})

@tcolgate https://github.com/tcolgate Have you tested this with an app registration (non-user SPN) ?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/bitly/oauth2_proxy/pull/470#discussion_r170063219, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEo80PcwYmvRBPzzIFyfF3Q2GnNDAySks5tXbyNgaJpZM4Pwk4y .

[johnarnold]

@tcolgate Thanks for responding. Testing with Azure Active Directory, it works ok with tokens generated from Device Code authentication tokens (which I think means the app is impersonating a user account via delegation) but fails with a straight up App Registration auth token:

Feb 23 00:55:13 netdocker1-eastus2 daemon INFO :  2018/02/23 00:55:13 oauthproxy.go:616: 172.17.0.6:47454 ("10.25.186.151") Cookie "_oauth2_proxy" not present
Feb 23 00:55:13 netdocker1-eastus2 daemon INFO :  2018/02/23 00:55:13 api.go:21: 404 GET https://graph.windows.net/me?api-version=1.6 {"odata.error":{"code":"Request_ResourceNotFound","message":{"lang":"en","value":"Resource not found for the segment 'me'."}}}
Feb 23 00:55:13 netdocker1-eastus2 daemon INFO :  2018/02/23 00:55:13 oauthproxy.go:670: 172.17.0.6:47454 ("10.25.186.151") invalid bearer token
Feb 23 00:55:13 netdocker1-eastus2 daemon INFO :  10.25.186.151 - - [23/Feb/2018:00:55:13 +0000] app.domain.com GET - "/oauth2/auth" HTTP/1.0 "python-requests/2.18.4" 401 21 0.093
Feb 23 00:55:13 netdocker1-eastus2 daemon INFO :  10.25.186.151 - - [23/Feb/2018:00:55:13 +0000] app.domain.com GET - "/oauth2/start?rd=/api/task/send-task/net_task.version" HTTP/1.1 "python-requests/2.18.4" 302 395 0.000

[johnarnold]

Is there a way to make it work with an Application? https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/entity-and-complex-type-reference#application-entity

Maybe just fetch the displayName instead of the emailAddress ?

[johnarnold]

Is this actually validating that this token has access to this endpoint? It looks like it's just verifying that to token has access to read the user's info in the directory. It could be a token without a valid claim to the application

I think you want to call p.Redeem(...) and make sure it's a valid code for the application.

[metaclassing]

@johnarnold in case your questions never got fully answered, I have done some testing with application tokens (vastly different from user or SPN tokens) and while they can talk to the graph API (scope https://graph.microsoft.com/.default) and look up group membership for example, they can not access the magic "/me" endpoint as so far as I have seen there is no appropriate directory object type to return.

aad 2.0 tokens issued with a scope/audience for the Microsoft graph API contain some kind of proprietary nonce field that makes them impossible to independently validate cryptographically, they can be used to access the graph API but not to authenticate the bearer in any other application.

The only way I have found to use aad application tokens in combination with other web services is to use aad 2.0 with the scope set to api://guid-of-other-application/.default and then send tokens directly which can be decoded and signature verified with RSA. These tokens do NOT contain the graph nonce field.

One challenge I have in other software is identifying the type of aad token presented, to determine if it is a user/spn/app and best method to select for verification. Microsoft's aad 2.0 documentation is somewhat poor and examples are overwhelmingly focused on their own languages.

[johnarnold]

@metaclassing I've done some preliminary work to properly validate claims, e.g. decoding the bearer token instead of using the /me uri. I believe it is doable. It may require specific client instructions for generating the correct token (e.g. OpenID). It's about 80% coded but not tested yet, I'll see if I can finish it up soon.

(I agree the docs are confusing.)

[johnarnold]

Not fully tested, but here's a working example of bearer token validation:

https://github.com/bitly/oauth2_proxy/compare/master...johnarnold:bearer2?expand=1

Was planning on expanding to support roles, too.

[metaclassing]

@johnarnold Very nifty looking, I merged it into my fork and will try to spin up an instance later this week to do some testing. I have had to write some other libs to interop with aad2.0 APIs and am very curious to see how this code handles the various different types of tokens I have seen generated. Thanks!

[eforbus]

I’d also like to see this PR approved along with added support for the OIDC provider.

[metaclassing]

After merging the PR into my fork I have been getting a build error:

oauth2_proxy/oauthproxy.go:756:28: p.provider.ValidateBearerToken undefined (type providers.Provider has no field or method ValidateBearerToken)

Would you mind terribly pointing me to what I messed up in doing the merge? Thanks!

[johnarnold]

@metaclassing I just rewrote a bunch of the code to better differentiate OpenID Connect tokens from (app reg.) access tokens. I'm testing against an internal version of Azure AD. I'll see if I can port the changes over to this pr too.