Oauth2 granular scopes

[marcellmars]

Enhancing Gitea OAuth2 Provider with Granular Scopes for Resource Access

This PR was initiated following my personal research to find the lightest possible Single Sign-On solution for self-hosted setups. The existing solutions often seemed too enterprise-oriented, involving many moving parts and services, demanding significant resources while promising planetary-scale capabilities. Others were adequate in supporting basic OAuth2 flows but lacked proper user management features, such as a change password UI.

Gitea hits the sweet spot for me, provided it supports more granular access permissions for resources under users who accept the OAuth2 application.

This PR aims to introduce this capability as nonintrusively and simply as possible. It acknowledges that the default scope is all and begins to process only additional scopes typical for OIDC/OAuth2: openid, profile, email, and groups. These then should be the ones already established with personal tokens.

Personal tokens define scopes around specific resources: user info, repositories, issues, packages, organizations, notifications, miscellaneous, admin, and activitypub, with access delineated by read and/or write permissions.

The initial case I wanted to address was to have Gitea act as an OAuth2 Identity Provider. To achieve that, with this PR, I would only add public-only and have no access to any API endpoint. The rest of the scopes should be provided as it is now, combining the existing Gitea OAuth2 scopes: openid, profile, email, and groups.

Another example: if a third party wanted to interact solely with Issues, it would need to add read:issue/write:issue to manage Issues.

Another scenario could involve adding read:user and public-only, preventing the third party from accessing anything the user has kept private.

My approach is based on my understanding of how scopes can be utilized, supported by examples like Sample Use Cases: Scopes and Claims on auth0.com.

I added an additional check to CheckOAuthAccessToken that returns AccessTokenScopeAll if no additional scopes or AccessTokenScope with whatever requested instead. That AccessTokenScope is then assigned to store.GetData()["ApiTokenScope"] in userIDFromToken to be checked against the accepted/stored grant scopes. The main difference is the opportunity to reduce the permissions from all, as is currently the case, to what is provided by the additional scopes described above.

The intent of this PR is to ensure that if nothing is added, or if scopes are added to openid, profile, email, groups but not in AccessTokenScope, everything continues to work as it currently does.

[techknowlogick]

Apologies if this is out of scope, but it might be useful to give a description next to the used scopes as a plain language would likely lower any chance at additional scopes are accepted mistakenly (def out of scope for this PR is including a warning if admin scope is requested)

[marcellmars]

Apologies if this is out of scope, but it might be useful to give a description next to the used scopes as a plain language would likely lower any chance at additional scopes are accepted mistakenly (def out of scope for this PR is including a warning if admin scope is requested)

are you thinking of adding plain language descriptions as code comments, or user interface changes that would warn users while they approve the required scopes?

currently, users are warned in the web ui about full access to all resources. are you suggesting we provide a clearer explanation of what happens when someone grants more limited or restrictive access?