Integrate an OAuth2 provider
tboerger opened this issue · 44 comments
To make it easier for other applications to hook into Gitea we should integrate an OAuth2 provider, that way tools like Drone CI can authenticate against Gitea much easier. A good library for that can be https://github.com/RangelReale/osin.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
Oh, sounds good this :)
Should this be integrated as "The" login-handler, or as an optional dependency? (i.e. build tag)
I think we can always integrate it but add an option for admins to disable it
No build tag but default is closed until admin open it.
Nice idea 👍
+1, this would be awesome!!!
is there an ETA for this? Would make life easier.
I think this one could be good option to integrate into gitea - https://github.com/coreos/dex
Here's another Go based alternative: https://github.com/ory/hydra
ORY Hydra is not an identity provider (user sign up, user log in, password reset flow), but connects to your existing identity provider through a consent app.
It seems quite easy to set up. Here's a nice tutorial: https://www.ory.am/run-oauth2-server-open-source-api-security.html?
@mikehaertl Hydra does not support JWT and from what I understand even if added they won't be in community edition - https://ory.gitbooks.io/hydra/content/faq.html#is-jwt-supported
JWT is a must have for drone integration
Remotely related, but would it also be possible to extend gitea so that gitea can listen on a second interface over which every access is granted automatically?
The idea is to allow tooling without OAuth2 authentication capabilities, like Hydra, to fetch data over, e.g., the loopback interface.
https://github.com/ory/fosite looks like a promising library to integrate this feature. It is used by hydra AFAIK.
IMHO https://github.com/coreos/dex looks more promising
Migrating all existing users would be a PITA though 😂
It would be fantastic if Gitea were its own OAuth2 provider! In fact, IndieAuth is the perfect candidate for how to implement this.
IndieAuth is an OAuth 2.0 extension, which avoids the centralized problems with existing OAuth solutions by using DNS for "registration" of client IDs and user IDs. Every user account is identified by a URL (for Gitea this could be your Gitea user page), and client IDs are also URLs (would be the Gitea instance home page in this case.)
This would let people sign in to other Gitea instances without any sort of prior relationship or doing client registration and such. Happy to walk through this in more detail if you're interested!
(originally posted at https://aaronparecki.com/2018/06/04/12/gitea-indieauth)
Sounds like it's comparable with openid connect.
Not quite, since OpenID Connect still requires registering clients to get client credentials to use with the flows. There is a dynamic client registration part of OpenID Connect, but this allows you to entirely bypass the need for registering clients separately since we just piggyback on the existing DNS for identifying clients.
(originally posted at https://aaronparecki.com/2018/06/04/18/)
I'll make an PRs for this one if nobody work on it
- 1 : Add OIDC lib and API
- 2 : Add Application managment
- 3 : Add Oauth HTTP HANDLER
@bkcsoft :D sorry openid Connect : http://openid.net/connect/
It's like openid3 based on oauth2
but i have dig more and i'll stick to Oauth2 for the moment
Because all big ( Gitlab, Github, etc... ) use Oauth
IMHO, integrate OAuth2 endpoints with maintained external lib (no point in reinventing the wheel) into API. Maybe even strip out code generation from authentication code flow and force only global/org scope. At least this would work for tools like Drone, registry etc.
@tarelda Oauth2 is realy simple protocol integrate an external library is just pointless, and many required library is already present in Gitea - 60% of the oauth or OIDC provider is the UI :)
I'll make the PR next week i had no time for finish the UI this week
@ekozan You can create a seperate PR for the UI, this may improve the review speed.
so, what library decided to use? i don't find any pr about oauth2 server in gitea
I'm waiting for this one as well. Definitely looking forward to it!
Is there a branch or PR related to this change? or we're still in the discussion phase.
@JohnTheodore no people are working on this.
That's unfortunate
@ekozan mentioned a PR, I wasn't sure if that happened.
@lunny it sounds like dex would be the library to use for resolving this issue? Are there changes to dex that are necessary for it to be the way you want?
In general how does the go-gitea project deal with something like a 'design document'. So if you, tboerger, lafriks, bkcsoft, etc all agree on a design with say dex, is that design written down somewhere? This way if someone wants to work on it, they'll do it in a way the project maintainers want.
We ever want to create a design process but in fact we haven't obey that because it's unnecessary for most features. We depend on Pull Requests approvals to control the quality of the codes. Any PR some maintainers against will be discussed more until two maintainers agreed and no maintainers against. A big PR of course should be required write the design detail on the PR's description. As an oauth provider, it's a mature technology.I think what we need to do is to find a maintained-well library and follow it's design.
i'm totaly busy .... :/ i havent finish the work
If anyone is interested in working on this, I wrote an adapter for https://github.com/go-oauth2/oauth2 that allows use of XORM https://github.com/techknowlogick/go-oauth2-xorm Next would be to add the routes to handle oauth.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 weeks. Thank you for your contributions.
There should be a way to mark this as "keep open", since there is clearly still demand for this.
There is a open PR too.
@lafriks Mind tagging this one as reviewed too? :)
Looking forward to this