oauth2-proxy: v7.3.0 breaks azure provider

I had to change the provider type to oidc and add oidc-issuer-url argument to make it work with version 7.3.0.

7.2.1

- --provider=azure
- --email-domain=example.com
- --upstream=file:///dev/null
- --http-address=0.0.0.0:1234
- --pass-user-headers

7.3.0

- --provider=oidc
- --email-domain=example.com
- --upstream=file:///dev/null
- --http-address=0.0.0.0:1234
- --pass-user-headers
- --oidc-issuer-url=https://login.microsoftonline.com/{TENANT_ID}/v2.0

@JoelSpeed, this is still an issue.

@JoelSpeed On my AKS cluster I use OAuth2-Proxy with Azure provider to authenticate the users and to authorise them to access the Kubernetes namespaces according to the AAD groups, they belong to. OAuth2-Proxy is installed with its Helm chart (version 6.8.0) and here are the extraArgs:

provider: "azure"
resource: "6dae42f8-4368-4678-94ff-3960e28e3630"
oidc-issuer-url: "https://sts.windows.net/{REDACTED_TENANT_ID}/"
azure-tenant: "{REDACTED_TENANT_ID}"
pass-access-token: "true"
pass-user-headers: "true"
set-xauthrequest: "true"
oidc-email-claim: sub
cookie-refresh: 59m
cookie-expire: 1h
cookie-domain: "{REDACTED_DOMAIN}"
whitelist-domain: ".{REDACTED_DOMAIN}"

After updating OAuth2-Proxy to 7.4.0 I get the same error in the logs, that is reported at the beginning of this thread: https://github.com/oauth2-proxy/oauth2-proxy/issues/1666#issue-1252488741

So I have switched to the Azure Auth V2 endpoint, as many have done in this thread by using the following extraArgs:

provider: "azure"
oidc-issuer-url: "https://login.microsoftonline.com/{REDACTED_TENANT_ID}/v2.0"
azure-tenant: "{REDACTED_TENANT_ID}"
pass-access-token: "true"
pass-user-headers: "true"
set-xauthrequest: "true"
oidc-email-claim: sub
cookie-refresh: 59m
cookie-expire: 1h
cookie-domain: "{REDACTED_DOMAIN}"
whitelist-domain: ".{REDACTED_DOMAIN}"
azure-graph-group-field: "id"

This lets the user authenticate to the AKS cluster, but it does not authorise them to access the Kubernetes namespaces, which require the AAD groups. I have checked the OAuth2-Proxy and it seems that the groups are acquired though:

[2023/01/24 14:46:16] [internal_util.go:69] 200 GET https://graph.microsoft.com/oidc/userinfo {"sub":"{REDACTED_SUB}","name":"{REDACTED_NAME}","family_name":"{REDACTED_FAMILYNAME}","given_name":"{REDACTED_GIVENNAME}","picture":"https://graph.microsoft.com/v1.0/me/photo/$value","email":"{REDACTED_EMAIL}"}
10.1.193.195:37276 - ca0bb03108a8692659f4424a5e74d8f9 - {REDACTED_SUB} [2023/01/24 14:46:16] [AuthSuccess] Authenticated via OAuth2: Session{email:{REDACTED_SUB} user: PreferredUsername: token:true id_token:true created:2023-01-24 14:46:15.464418172 +0000 UTC m=+385.805287758 expires:1970-01-01 00:00:00 +0000 UTC groups:[{REDACTED_GROUP1} {REDACTED_GROUP2} ... {REDACTED_GROUPN}]}

As you can see the session’s expiration is set to 1970-01-01 00:00:00 +0000 UTC: do you know what the issue could be? It is strange that the Azure Auth V2 endpoint returns me an expired session.

@rouke-broersma Thanks for the heads up, I can look into that. The other issue really is time. I’m pretty short on it these days given this is now a hobby project and not something my employer grants me time to work on. Realistically we need to find engaged maintainers for each provider who can put in the time to make sure their providers are still working as we make changes

@pierluigilenoci and others, I am also using Azure AD with AKS and following are my findings

• X-Auth-Request-Access-Token token has groups info in payload but Authorization token doesn’t contain groups info in payload.

• While I was able to successfully log in to the Kubernetes Dashboard, I encountered issues with the authorization process as per RBAC. In order to investigate further, I performed manual testing by obtaining the token and testing it with the Kubernetes API. SelfSubjectReview ( its purpose is to find out how Kubernetes cluster maps authentication information to identify me as a client.)

  1. I found that using the token obtained via kubelogin and including it in the Authorization header allowed me to access all the resources in the Kubernetes dashboard.

  2. I encountered an issue where the token returned by oauth2_proxy was resulting in an “unauthorized” error.

  3. Upon decoding both tokens, I discovered a difference in the “aud” (audience) value. The token obtained through kubelogin had the “aud” value set to “6dae42f8-4368-4678-94ff-3960e28e3630”, while the token acquired via oauth2 had the “aud” value set to “https://graph.microsoft.com/”.

  4. I attempted to update the “aud” value in oauth2_proxy by setting the resource value to “6dae42f8-4368-4678-94ff-3960e28e3630”, but encountered an error. [azure.go:105] WARNING: --resource option has no effect when using the Azure OAuth V2 endpoint.

To verify this further, I conducted testing using the following two commands: az account get-access-token --resource https://management.azure.com --> unauthorize az account get-access-token --resource 6dae42f8-4368-4678-94ff-3960e28e3630 --> authorize

Is there any way we can add resource in v2 ?

PS: It is the same application ID 6dae42f8-4368-4678-94ff-3960e28e3630 in all clouds for Kubernetes Service.

@JoelSpeed fyi an azure tenant can be created for free, at which point you will have access to all features you need to test authentication. They are free features and as far as I know don’t even require a credit card attached. If necessary I can create a tenant for you and hand it over to you, if interested.

As far as requiring setting the oidc issuer url, I wonder what the use of the azure specific provider is at that point. I would expect that choosing a specific provider makes working with that provider easier because it uses sane defaults. At most I would expect to pass the tenant id to the config and for the provider to figure out what the exact issuer url is. Would it not make more sense to just always use the oidc provider if we have to provide the full oidc config anyway? Or am I missing something?

I got it working with v7.5.1, in my case I don’t need the proxy to fetch the groups, because this is done by AKS managed identity. Here’s my configuration:

provider: oidc
oidc-issuer-url: https://login.microsoftonline.com/[REDACTED]/v2.0
login-url: https://login.microsoftonline.com/[REDACTED]/oauth2/v2.0/authorize
redeem-url: https://login.microsoftonline.com/[REDACTED]/oauth2/v2.0/token
oidc-jwks-url: https://login.microsoftonline.com/[REDACTED]/discovery/v2.0/keys
skip-oidc-discovery: true
user-id-claim: email
oidc-email-claim: sub
oidc-audience-claim: aud
scope: openid 6dae42f8-4368-4678-94ff-3960e28e3630/.default
pass-access-token: true
pass-user-headers: true
set-xauthrequest: true

The scope openid is required when authenticating using oidc, 6dae42f8-4368-4678-94ff-3960e28e3630/.default is the scope for Azure Kubernetes Service AAD Server.

Related issue: https://github.com/oauth2-proxy/oauth2-proxy/issues/2314

@JoelSpeed @steakunderscore @NickMeves, any news around this?

Project ded rip

This issue should be added to the breaking changes for the v7.3.0 release.

Hello @JoelSpeed, I have found the issue.

In this func, you had the azure provider set to true.

func providerRequiresOIDCProviderVerifier(providerType options.ProviderType) (bool, error) {
	switch providerType {
	case options.BitbucketProvider, options.DigitalOceanProvider, options.FacebookProvider, options.GitHubProvider,
		options.GoogleProvider, options.KeycloakProvider, options.LinkedInProvider, options.LoginGovProvider, options.NextCloudProvider:
		return false, nil
	case options.ADFSProvider, options.GitLabProvider, options.KeycloakOIDCProvider, options.OIDCProvider, options.AzureProvider:
		return true, nil
	default:
		return false, fmt.Errorf("unknown provider type: %s", providerType)
	}
}

This then causes the Azure provider to move through the oidc setup, which causes both problems:

1st problem is that the issuerURL must be set. 2nd Problem is that the graph api returns a 400.

What is actually happening is the provider setup is reaching out to the issuerURL and populating the profile URL from here, (which is actually )

https://login.windows.net/{tenant}/openid/userinfo

from there everything is set, and the Azure init (which relies on empty values to set the azure defaults) fails.

Add Azure into the false case, and it is unbroken.

About a year has passed since several users had problems running the Azure provider. Judging by the comments here, the problem has been fairly cleared up. It may be time to find someone to handle and resolve the situation. What do you think? @JoelSpeed @steakunderscore @NickMeves

For completeness, I also add all the provider’s contributors (maybe someone driven by a positive spirit takes charge of the situation). @adriananeci @ianroberts @weinong @codablock @johejo @wonderhoss @theonewolf @pasha-r @leyshon @MisterWil @jehiah @eelcocramer

Thank you all for the effort invested in the project so far and for what you will invest in the future.

seeing a similar issue as @vittoriocanilli i am able to use it but userinfo is missing… it only seems to be grabbing user email but the rest are blank.

@erikgb I just tried with 7.4 and still seeing the same error.

@JoelSpeed already did, 6 days ago: #1771

That’s not really updating the documentation. The azure provider is broken and the instructions found here: https://github.com/oauth2-proxy/oauth2-proxy/blob/master/docs/docs/configuration/auth.md#azure-auth-provider are no longer working.

@JoelSpeed already did, 6 days ago: https://github.com/oauth2-proxy/oauth2-proxy/pull/1771

Update: Working fine with this setup:

config:
  existingSecret: oauth2-secret
ingress:
  enabled: true
  className: nginx
  path: /
  hosts:
    - oauth.***.com
  tls:
  - hosts:
    - oauth.***.com
    secretName: tls-***
service:
  portNumber: 4180
extraArgs:
  provider: oidc
  redirect-url: https://oauth.***.com/oauth2/callback
  oidc-issuer-url: https://login.microsoftonline.com/***/v2.0
  cookie-refresh: 10m
  cookie-expire: 15m
  cookie-domain: .***.com
  pass-access-token: true
  scope: openid email profile
  upstream: https://***.***.com
  set-xauthrequest: true
  whitelist-domain: .***.com
  email-domain: "*"
sessionStorage:
  type: redis
redis:
  enabled: true

@knightian yes, I am using:

oidc_issuer_url = "https://login.microsoftonline.com/<tenant-id>/v2.0"
profile_url = "https://graph.microsoft.com/v1.0/me"
login_url = "https://login.microsoftonline.com/<tenant-id>/v2.0/oauth2/authorize"
redeem_url = "https://login.microsoftonline.com/<tenant-id>/v2.0/oauth2/token"
oidc_jwks_url = "https://login.microsoftonline.com/common/discovery/keys"

The Azure AD app is configured for v2 in the manifest: "accessTokenAcceptedVersion": 2

@knightian it does, but you need to use the group IDs instead of the group names because group names are not returned for oidc.

I can confirm that the suggestion from @AureaMohammadAlavi in https://github.com/oauth2-proxy/oauth2-proxy/issues/1666#issuecomment-1145838016 works for me/us! Thanks! I am not sure if there are any downsides using the standard oidc-provider with Azure? Maybe the azure-provider should be deprecated and eventually removed?

Looks like GitHub auth is also having issues. Is there any pertinent security issues that are addressed in this or is it fine to roll back and live on 7.2.1?

There has been a very long time since the 7.2.1 release, so my main concern is security vulnerabilities in the container images, some of them critical. I would prefer an urgent bugfix to the borked 7.3.0 release.