Open marcellmars opened 2 months ago
Hi @marcellmars, thanks for this issue. Sorry you didn't get a response sooner. This is most definitely planned, and so I'll reopen this issue so it can be tracked.
Hi @marcellmars, thanks for this issue. Sorry you didn't get a response sooner. This is most definitely planned, and so I'll reopen this issue so it can be tracked.
Thanks for coming back.
If anyone gets into it, maybe they can cherry-pick it back from Forgejo, where I expanded this initial idea, with great support from the community, into a PR.
Feature Description
Title
"Enhancing OAuth2 Scopes in Gitea for More Granular Access Control"
Hi everyone,
After some research among OAuth2 provider solutions, I ended up with a desire for Gitea to handle that job! ;)
Gitea is useful for more than just coder communities. It doesn't require too many resources and does a great job managing users and allowing them to maintain their accounts.
Other solutions I found either ask for enterprise requirements or don't do a good enough job managing users.
For my use case, Gitea does exactly what I expect from an OAuth2 provider, except for the granular settings of what resources can be accessed through OAuth2 clients using Gitea as the OAuth2 provider.
From my understanding, Gitea serves the usual suspects such as
openid
,profile
,email
, andgroups
, but it also implicitly addsread/write all
so every token gets access to everything under the user who accepts the OAuth2 client/service. That has obviously served all the users well so far.I think it would be great if OAuth2 clients could ask for what they need by requesting additional scopes such as
read:user
,read:repository
,read:issue
,write:issue
,public-only
, etc.In my case, I would be happy to ask Gitea to only allow
read:user
. This would make Gitea the best OAuth2 provider for me.This itch pushed me into my first attempt to hack on Gitea.
I found that I could add a check for additional scopes in CheckOAuthAccessToken and pass it further so it could be used in userIDFromToken. Instead of
store.GetData()["ApiTokenScope"] = auth_model.AccessTokenScopeAll
(which allows access to all resources under the user), the scopes requested by the OAuth2 client are used.The new function
grantAdditionalScopes
adds only the scopes found asAccessTokenScope
(all
,public-only
,read:activitypub
,write:activitypub
,read:admin
,write:admin
,read:misc
,write:misc
etc..This means one could ask for read-only access to
user
,issue
, andactivitypub
withread:user
,read:issue
, andread:activitypub
. This would come after the usual OAuth2 suspects:openid
,profile
,email
, andgroups
.My approach here is based on reading and understanding how scopes might be used, and one of the examples I found that confirm my understanding is Sample Use Cases: Scopes and Claims at auth0.com.
In my internal tests, this worked fine. I'm not sure if this is the best direction.
While working on this, I felt it would be nice to list requested scopes in the consent snippet for client authorization.
It shouldn't be a big deal to even add the possibility for the user to change/reduce the requested scopes.
Here are a few snippets that made it work for me. I'm interested to hear your feedback on this.