I think you're right, we are checking the groups when loading the session but not when creating it, we need both I think.

@NickMeves I know you were heavily involved in reviewing the changes for the group additions, do you know if this was something that was skipped deliberately or was this just missed?

Provider ValidateGroup is a Google provider only method, no other Provider implemented that method. We looked at it originally in the Groups PR, but it taking in an Email made it very focused on Google's use case.

I completely removed it in this refactor: #797

Let me look and see if groups validation is needed in general in the callback though. I think you might be right, this is after the redeemCode and future EnrichSessionState logic, so all sessions should be completely configured at this point in the flow and ready for authorization.

Hmmmm - we did have a discussion about how this whole process works in a world where existing sessions were provisioned, but then the oauth2-proxy configuration changes (and added or removed required groups).

I'll need to think through if that scenario merits anyone getting a session & authZ check on group membership being a later stage.

I think with the current design of this refactor I'm working #797 - I view AuthN & AuthZ as split paradigms.

• We'll authenticate freely to give you a session (hence callback allowed).
• Then we'll authorize check the group membership on attempted access to resources.

This might lend itself better to a future world where the AuthZ is more configurable on a per route basis. If userinfo actually gave Groups back (#850) -- I could see that being handy for endusers to debug why they AuthN but fail AuthZ

I am not good in authorization processes but want to propose: After user reached a callback page and he has no access to it - he should be redirected to different path without any GET params to make page reload possible and safe (without re-validation of already checked and non-valid token)

I see the circular redirect concerns in the subrequest K8s ingress annotation design (that I don't think would happen in traditional upstream deployments, they would get the 401 Unauthorized on the redirect URL directly -- rather than Nginx catching that from auth URL and redirecting to the sign-in annotation URL).

I think for that reason alone, you are right -- for Global group/role based Authorization, we should perform this authorization on the callback.

Do you want to try making a PR with the fix?

Created a PR: #855
But I did not found a proper place to place tests for this feature.

Fixed in this PR: #797