OAuth tokens vs. blocked users

This came up in gitlab-ce!8018 (discussion here): when a user is blocked/ldap-blocked, their OAuth access grants/tokens are still valid and could theoretically be used to access APIs.

My first approach was to simply deleted these tokens when a user is blocked, but that brings up a few concerns:

• users have to reauthorize their OAuth clients after they're unblocked
• revoked tokens should always be kept in the DB (see related discussion on Doorkeeper's issue tracker)

To avoid these issues, I think it would be easier to simply add a check for blocked users in AccessTokenValidationService and return an appropriate error response (e.g. TokenNotFoundError).

Unfortunately I currently don't have any time to look into this, so I'll leave it up to you :)

/cc gitlab-ce2677572 gitlab-ce4107687 gitlab-ce~2779335

added ~480950 ~17488 ~287618 ~14106 labels

Closing this issue due to no updates within the past year. @toupeira if you think this is still an issue, please feel free to reopen and we can prioritize accordingly.

closed

@jritchey hmm I do think this is still a potential issue and requires some careful investigation of Gitlab::Auth. At the moment it seems only find_with_user_password directly checks the user's active state, but the checks for OAuth access tokens and personal access tokens only verify the token validity.

reopened

added Manage [DEPRECATED] label

Why is this security issue has "cosmetic" severity?

added devopsmanage label

added [deprecated] Accepting merge requests label

added groupauthentication and authorization [DEPRECATED] label

removed [deprecated] Accepting merge requests label

added 1 deleted label

assigned to @dblessing

changed milestone to %13.3

I don't believe this is still an issue. In https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/auth.rb the appropriate authentication methods check that the user can?(:log_in), which uses a policy that checks for blocked/inactive users.

The policies that enable/prevent :log_in can be found at https://gitlab.com/gitlab-org/gitlab/-/blob/c74d99859b0700f2f966a7c9fe1829a320139b9b/app/policies/global_policy.rb#L26-70

For authenticating via Git with an OAuth token, the policy is checked at https://gitlab.com/gitlab-org/gitlab/-/blob/c74d99859b0700f2f966a7c9fe1829a320139b9b/lib/gitlab/auth.rb#L173.

For authenticating via personal access token, the policy is checked at https://gitlab.com/gitlab-org/gitlab/-/blob/c74d99859b0700f2f966a7c9fe1829a320139b9b/lib/gitlab/auth.rb#L185.

This check is also in place for validating build access tokens at https://gitlab.com/gitlab-org/gitlab/-/blob/c74d99859b0700f2f966a7c9fe1829a320139b9b/lib/gitlab/auth.rb#L265

As @toupeira mentioned a while back, the check is already in place for find_user_with_password.

I did a manual validation with an access token and was denied access when the user was blocked.

I'm not sure if Git authentication was the only concern at the time. If anyone knows of other avenues I should check, please let me know. Otherwise, I think we're pretty well covered here.

@dblessing thanks for checking, I agree that this looks good now!

The original concern was authenticating our REST API with an OAuth2 access token (as in https://docs.gitlab.com/ee/api/#oauth2-tokens), I played through that now on staging and also get {"message":"403 Forbidden - Your account has been blocked."} after disabling the user.

Perfect. Thanks for clarifying and confirming.

closed

removed milestone %13.3