I'm using oauth2_proxy in conjunction with keycloak. This works without problems (hint: as there is no oidc enabled release, you have to compile oauth2_proxy from the master branch on your own).
However, I'm now trying to restrict the users that could login through oauth2_proxy by using (oidc) scopes. My expectation is that when using the scope flag (let's say -scope admin) the login (and the proxy use afterwards) is only possible for users whose id token (or access token or userinfo) provides (at least) the scope admin.
Hence I tested this. Result: this is not the case, i.e. using -scope admin and login to keycloak with a user that does not include the admin scope is possible (so far not a problem) and using the upstream of oauth2_proxy is granted (bug in oauth2_proxy).
I would expect that the keycloak login is possible (if there is such a user) but after the redirect, access to upstream is denied (as the granted bearer token does not include the admin scope).
I'm using oauth2_proxy in conjunction with keycloak. This works without problems (hint: as there is no oidc enabled release, you have to compile oauth2_proxy from the master branch on your own).
However, I'm now trying to restrict the users that could login through oauth2_proxy by using (oidc) scopes. My expectation is that when using the scope flag (let's say
-scope admin) the login (and the proxy use afterwards) is only possible for users whose id token (or access token or userinfo) provides (at least) the scopeadmin.Hence I tested this. Result: this is not the case, i.e. using
-scope adminand login to keycloak with a user that does not include theadminscope is possible (so far not a problem) and using the upstream of oauth2_proxy is granted (bug in oauth2_proxy).I would expect that the keycloak login is possible (if there is such a user) but after the redirect, access to upstream is denied (as the granted bearer token does not include the
adminscope).