Integrate an OAuth2 provider about gitea HOT 44 CLOSED

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)

from gitea.

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

from gitea.

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.

from gitea.

Looking forward to this

from gitea.

I think this one could be good option to integrate into gitea - https://github.com/coreos/dex

from gitea.

@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

from gitea.

I think we can always integrate it but add an option for admins to disable it

from gitea.

Oh, sounds good this :)

from gitea.

Nice idea 👍

from gitea.

is there an ETA for this? Would make life easier.

from gitea.

https://github.com/ory/fosite looks like a promising library to integrate this feature. It is used by hydra AFAIK.

from gitea.

IMHO https://github.com/coreos/dex looks more promising

from gitea.

@ekozan Mind linking to "OIDC" since I have no clue what that is 🙂

from gitea.

Should this be integrated as "The" login-handler, or as an optional dependency? (i.e. build tag)

from gitea.

No build tag but default is closed until admin open it.

from gitea.

@tboerger @lunny I was more wondering if all Authentication should be handled by OAuth, therefore removing the old auth-module

from gitea.

+1, this would be awesome!!!

from gitea.

@lafriks Looks good, but it requires go1.8 I think.

from gitea.

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?

from gitea.

@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

from gitea.

JWT is a must have for drone integration

from gitea.

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.

from gitea.

Migrating all existing users would be a PITA though 😂

from gitea.

Sounds like it's comparable with openid connect.

from gitea.

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/)

from gitea.

@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

from gitea.

I need some help and advise on the design :)

Do you think i'm right :

• Every User can create an oauth app
• Every Org can create an oauth app
• Gitea admin can create offical app

@tboerger @bkcsoft @lunny

from gitea.

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.

from gitea.

@ekozan just like github, I think. :)

from gitea.

@ekozan You can create a seperate PR for the UI, this may improve the review speed.

from gitea.

so, what library decided to use? i don't find any pr about oauth2 server in gitea

from gitea.

I'm waiting for this one as well. Definitely looking forward to it!

from gitea.

Is there a branch or PR related to this change? or we're still in the discussion phase.

from gitea.

@JohnTheodore no people are working on this.

from gitea.

That's unfortunate

from gitea.

@ekozan mentioned a PR, I wasn't sure if that happened.

from gitea.

@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.

from gitea.

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.

from gitea.

i'm totaly busy .... :/ i havent finish the work

from gitea.

@ekozan never mind. :)

from gitea.

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.

from gitea.

There should be a way to mark this as "keep open", since there is clearly still demand for this.

from gitea.

There is a open PR too.

from gitea.

@lafriks Mind tagging this one as reviewed too? :)

from gitea.