Problem with OIDC specifically when authenticating against an Azure tenant in GCC High

[nusol-sc]

We have been using Authentik as part of our default stack for close to a year, and almost exclusively has used OIDC with Azure AD without issue. We now have two customers where this is not working, and the common thread is that both of their tenants are in GCC High.

Authentication appears to be working. Using the browser developer tools I can see the request sent to the authorize endpoint succeeds with a 302 response and cookies are set. Also, subsequent requests no longer redirect to Azure, further suggesting that authentication was successful. Deleting the cookies resets the session and forces re-authentication. The standard toast notification that appears in the top-right of the window reports the following: Authentication failed: Could not retrieve profile.

Following is a heavily redacted copy of the log entries that result from the error. I modified the URLs, IP addresses, and the code.

INF auth_via=unauthenticated client_id=0abcdef0-dead-beef-cafe-123abcdef456 domain_url=auth.redacted.example.com event=redirect args host=auth.redacted.example.com logger=authentik.sources.oauth.clients.base pid=55 redirect_uri=https://auth.redacted.example.com/source/oauth/callback/redacted-azure-ad/ request_id=11cb6b0429d04f0e8d10f05b08ecdce9 response_type=code schema_name=public scope=https://graph.microsoft.com/User.Read openid source=redacted-azure-ad state=8vbxYlHgUlCcYH2JXbxCAT6tKGRVi6yj timestamp=2024-09-10T23:49:29.727326

INF auth_via=unauthenticated domain_url=auth.redacted.example.com event=/source/oauth/login/redacted-azure-ad/ host=auth.redacted.example.com logger=authentik.asgi method=GET pid=55 remote=xxx.xxx.xxx.xxx request_id=11cb6b0429d04f0e8d10f05b08ecdce9 runtime=23 schema_name=public scheme=https status=302 timestamp=2024-09-10T23:49:29.730424 user= user_agent=Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0

INF domain_url=null event=/ws/client/ logger=authentik.asgi pid=54 remote=xxx.xxx.xxx.xxx schema_name=public scheme=ws timestamp=2024-09-10T23:49:29.956381 user_agent=Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0

warning auth_via=unauthenticated domain_url=auth.redacted.example.com event=Unable to fetch user profile exc=HTTPError('401 Client Error: Unauthorized for url: https://graph.microsoft.us/oidc/userinfo') host=auth.redacted.example.com logger=authentik.sources.oauth.clients.oauth2 pid=55 request_id=61e1d3e0368940549b3336918ff8cad8 response=401 Client Error: Unauthorized for url: https://graph.microsoft.us/oidc/userinfo schema_name=public timestamp=2024-09-10T23:49:31.725465

warning auth_via=unauthenticated domain_url=auth.redacted.example.com event=Authentication Failure host=auth.redacted.example.com logger=authentik.sources.oauth.views.callback pid=55 reason=Could not retrieve profile. request_id=61e1d3e0368940549b3336918ff8cad8 schema_name=public timestamp=2024-09-10T23:49:31.725817

followed by 6 null characters, and then the following (which appears to be truncated -- perhaps that is an issue with how portainer captures the logs...I don't know where the authentik logs are on the server...I'm still searching):

via": "unauthenticated", "domain_url": "auth.redacted.example.com", "event": "/source/oauth/callback/redacted-azure-ad/?code=redacted-code&state=8vbxYlHgUlCcYH2JXbxCAT6tKGRVi6yj&session_state=927738c3-96cf-4ae3-a038-4b928fe886c0", "host": "auth.redacted.example.com", "level": "info", "logger": "authentik.asgi", "method": "GET", "pid": 55, "remote": "xxx.xxx.xxx.xxx", "request_id": "61e1d3e0368940549b3336918ff8cad8", "runtime": 1034, "schema_name": "public", "scheme": "https", "status": 302, "timestamp": "2024-09-10T23:49:31.734183", "user": "", "user_agent": "Mozilla/5.0 (X11; Linux x86_64; rv:130.0) Gecko/20100101 Firefox/130.0"}

When using GCC High, the domain is different. As opposed to the normal login.microsoftonline.com domain, login.microsoft.us is used instead. While the Profile URL should be graph.microsoft.us/oidc/userinfo, I have tried various other URLs as well, for both OIDC v1 and v2, and even using the standard domain. Nothing works.

It looks very much like there is a problem passing the authorization token.