oauth2-proxy: Custom OIDC groups claim along with allowed groups query parameter always returns 403
-
I am using Auth0 as the OIDC provider. They only allow custom claims that are name-spaced. Therefore I can’t use the default “groups” as the oidc_groups_claim. I override this in the configuration with a custom claim string (see below under steps to reproduce)
-
I get a successful 202 response from oauth proxy when there is no
allowed_groups
query parameter (see ngnix config below) -
As soon as I add an allowed_groups query parameter with a single group to verify I get a forbidden 403 error
-
This response is incorrect as the user logged in is part of the group specified by the custom claim (see token below)
-
I have looked through the code and I believe oauthproxy.go
checkAllowedGroups
is returning false due to the session State not containing the group
Expected Behavior
The method checkAllowedGroups
should return true if the ID Token contains a custom group claim matching the query parameter. This would then mean oauth proxy returns 202 and lets the request through
Current Behavior
Either the session state does not contain the groups based on the oidc_groups_claim
OR it is not correctly matching from the query parameter
Possible Solution
The code seems pretty well unit tested so I’m struggling to see where this could be going wrong. Perhaps a test around the extractAllowedEntities
function
The CreateSessionFromToken
function seems to be well unit tested. However, I can’t find a test that verifies token parsing with a custom groups claim actually populates the session state Group correctly.
I am sure this is a small fix. I imagine it to only be a small code change. Any assistance pointing me in the right direction would be great.
Steps to Reproduce (for bugs)
Legacy configuration
provider = "oidc"
oidc_groups_claim = "https://members.com/groups"
email_domains = ["*"]
cookie_domains=".the-app-company.com"
whitelist_domains=[".the-app-company.com"]
reverse_proxy = true
…
Nginx configuration
location / {
auth_request /internal-auth/;
error_page 401 = https://oauth2.the-app-company.com/oauth2/start?rd=$scheme://$host$request_uri;
proxy_pass http:/allowed_upstream_server;
}
location /internal-auth/ {
internal; # Ensure external users can't access this path
# Make sure the OAuth2 Proxy knows where the original request came from.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_pass_request_body off;
proxy_set_header Content-Length "";
proxy_set_header X-Original-URI $request_uri;
# This is the only way to send allowed groups to oauth proxy otherwise the ? get's encoded to %3F and no longer matches the correct path
proxy_pass http://oauth2-proxy:4180/oauth2/auth?allowed_groups=member;
}
JWT ID Token
{
"https://members.com/groups": [
"member"
],
"nickname": "andrebarrett",
"name": "Andre",
"picture": "https://s.gravatar.com/avatar/d461c627c81d53ac46c143ae49df2ed5?s=480&r=pg&d=https%3A%2F%2Fcdn-icons-png.flaticon.com%2F512%2F149%2F149071.png",
"updated_at": "2022-07-15T06:06:48.428Z",
"email": "andrebarrett@hotmail.co.uk",
"email_verified": true,
"iss": "https://dev-bka5l41i.auth0.com/",
"sub": "auth0|5e9b5e5c63f8000c8c20d541",
"aud": "uU2CJnAgxtI5yH81viwlrTlB9p8k5qMn",
"iat": 1657865210,
"exp": 1657901210
}
User Info Endpoint
{
"sub": "auth0|5e9b5e5c63f8000c8c20d541",
"nickname": "andrebarrett",
"name": "Andre",
"picture": "https://s.gravatar.com/avatar/d461c627c81d53ac46c143ae49df2ed5?s=480&r=pg&d=https%3A%2F%2Fcdn-icons-png.flaticon.com%2F512%2F149%2F149071.png",
"updated_at": "2022-07-15T06:06:48.428Z",
"email": "andrebarrett@hotmail.co.uk",
"email_verified": true,
"https://members.com/groups": ["member"]
}
Steps to reproduce
- Use OIDC provider such as Auth0
- Use a custom groups claim in config
- Use nginx auth_request module
- Have a allowed_groups query with a group go to the oauth proxy pass
- Login using a user that is part of the allowed group
- See the request fail with a 403
Context
I am trying to secure various upstream websites.
- Only members of the admin group should be able to access some of the websites (metrics.domain.com for example).
- Individuals without a group should be able to access the public website (www.domain.com for example)
- And only subscribed members should be able to access the portal (members.domain.com for example)
Your Environment
Tested with a docker compose setup. Used Ubuntu for both containers running nginx and oauth proxy. Ran from an M1 Mac
- Version used: Latest v7.3.0.linux-amd64 version, prebuilt binary downloaded from release
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 2
- Comments: 20 (11 by maintainers)
not stale -.-