oauth2-proxy: Azure provider with v7.2.1 and ADAL stop working - Access token validation failure. Invalid audience

After the update from v7.2.0 to v7.2.1 the integration with the AAD stops working. We analyzed the difference between the two versions and we understood our issue is this PR: #1433

The pod produces these loglines:

[2022/01/06 13:32:29] [internal_util.go:74] token validation request failed: status 401 - {"error":{"code":"InvalidAuthenticationToken","message":"Access token validation failure. Invalid audience.","innerError":{"date":"2022-01-06T13:32:29","request-id":"[REDACTED]","client-request-id":"[REDACTED]"}}}
[2022/01/06 13:32:29] [internal_util.go:69] 401 GET https://graph.microsoft.com/v1.0/me {"error":{"code":"InvalidAuthenticationToken","message":"Access token validation failure. Invalid audience.","innerError":{"date":"2022-01-06T13:32:29","request-id":"[REDACTED]","client-request-id":"[REDACTED]"}}}
10.5.1.44:59808 - [REDACTED] - [REDACTED] [2022/01/06 13:32:29] [AuthFailure] Session validation failed: Session{email:[REDACTED] user: PreferredUsername: token:true id_token:true created:2022-01-06 13:32:29.287771102 +0000 UTC m=+2927.613337671 expires:2022-01-06 14:44:17 +0000 UTC refresh_token:true}

We analyzed the code. Here is the code involved:

Our pod is running in this way:

--http-address=0.0.0.0:4180
--metrics-address=0.0.0.0:44180
--azure-tenant=[REDACTED]
--cookie-domain=[REDACTED]
--cookie-expire=1h
--cookie-refresh=59m
--oidc-email-claim=sub
--oidc-issuer-url=https://sts.windows.net/[REDACTED]/
--pass-access-token=true
--pass-user-headers=true
--provider=azure
--resource=6dae42f8-4368-4678-94ff-3960e28e3630
--set-xauthrequest=true
--whitelist-domain=.[REDACTED]
--config=/etc/oauth2_proxy/oauth2_proxy.cfg

We use Managed AAD with our AKS clusters. We configure OAuth2 Proxy to work with ADAL but the request for the validation is made to MSAL. We presume this problem is strictly connected to #1144 and #1231

Expected Behavior

We expect that the Azure provider is able to validate the token using the same Graph endpoint version or at least it must be able to work.

Your Environment

  • Version used: AKS 1.21.2

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 12
  • Comments: 33 (27 by maintainers)

Most upvoted comments

I just got my cluster and oauth-proxy re-configured using older version. everything is working so far. I will try the new version soon!

i’m working on the fix and please be patient with me 😄

@JoelSpeed thank you a lot. 🚀 If I were kind enough to also take a look at the PR #1574 to close this issue it would be great. ❤️

That’s what I referenced already had my approval but needs to address Joel’s comments.

I think it’s also happening with Keycloak, as seen in https://github.com/oauth2-proxy/oauth2-proxy/issues/1599 Looks like, it also had a token validation error that was ignored previously, but now results in authentication failure.

The fix can be simple: I don’t see any need to validate the access token in a session by calling the Graph API. If @JoelSpeed and @NickMeves agree, I can work on the PR.

@stippi2 is right. We should be validate the session. It’s just unfortunate…

@weinong you should ask @stippi2 (the author of the PR #1433 used to fix #1396)

Please don’t confuse what my PR did. The call to ValidateSession() was already in the code. But the return value of that check was ignored, which was clearly not the intention. What my PR exposes is that ValidateSession() never worked in the first place for the Azure provider. Please note that the return value of ValidateSession() was correctly checked when the session is refreshed. So for the Azure provider, it would have failed at that point at the latest, also before my PR was merged.

@pierluigilenoci Sorry for being late to the party. We are using keycloak together with oauth2-proxy. So the actual configuration for Azure is happening in keycloak. We got it running with oauth2-proxy only but we need some additional features which only keycloak was able to provide. The FAQ on the oauth2-proxy on how to use the proxy with keycloak worked perfectly fine.

@pierluigilenoci I can only say that we stopped using oauth2-proxy and Azure. We now use dex as an anti-corruption layer between Azure and oauth2-proxy as it seems to be more stable in regard to Azure. I can not give any advice/feedback on oauth2-proxy + Azure anymore.