Integrate an OAuth2 provider about gitea

[aaronpk]

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)

[ekozan]

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

[techknowlogick]

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.

[xdevs23]

Looking forward to this

[lafriks]

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

[ekozan]

@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

[tboerger]

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

[joubertredrat]

Oh, sounds good this :)

[joubertredrat]

Nice idea 👍

[femaref]

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

[jonasfranz]

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

[tboerger]

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

[bkcsoft]

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

[bkcsoft]

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

[lunny]

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

[bkcsoft]

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

[JohnTheodore]

+1, this would be awesome!!!

[lunny]

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

[mikehaertl]

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?

[lafriks]

@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

[tboerger]

JWT is a must have for drone integration

[ts468]

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.

[bkcsoft]

Migrating all existing users would be a PITA though 😂

[tboerger]

Sounds like it's comparable with openid connect.

[aaronpk]

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

[ekozan]

@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

[ekozan]

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

[tarelda]

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.

[lunny]

@ekozan just like github, I think. :)

[jonasfranz]

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

[vtolstov]

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

[xdevs23]

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

[JohnTheodore]

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

[lunny]

@JohnTheodore no people are working on this.

[xdevs23]

That's unfortunate

[JohnTheodore]

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

[JohnTheodore]

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

[lunny]

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.

[ekozan]

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

[lunny]

@ekozan never mind. :)

[stale]

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.

[AfroThundr3007730]

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

[jonasfranz]

There is a open PR too.

[AfroThundr3007730]

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