You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 24, 2019. It is now read-only.
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).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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 admin
and login to keycloak with a user that does not include theadmin
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).The text was updated successfully, but these errors were encountered: