Integrate an OAuth2 provider

[tboerger]

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.

[joubertredrat]

Oh, sounds good this :)

[joubertredrat]

Oh, sounds good this :)

[bkcsoft]

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

[bkcsoft]

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

[tboerger]

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

[tboerger]

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

[lunny]

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

[lunny]

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

[joubertredrat]

Nice idea 👍

[joubertredrat]

Nice idea 👍

[bkcsoft]

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

[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!!!

[JohnTheodore]

+1, this would be awesome!!!

[femaref]

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

[femaref]

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

[lafriks]

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

[lafriks]

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

[lunny]

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

[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?

[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

[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

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

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

[JonasFranzDEV]

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

[JonasFranzDEV]

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

[tboerger]

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

[bkcsoft]

Migrating all existing users would be a PITA though 😂

[bkcsoft]

Migrating all existing users would be a PITA though 😂

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

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

[tboerger]

Sounds like it's comparable with openid connect.

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

[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]

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

[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

[bkcsoft]

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

[bkcsoft]

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

[techknowlogick]

I think OIDC == OpenID Connect

[techknowlogick]

I think OIDC == OpenID Connect

[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]

@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

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

[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. :)

[lunny]

@ekozan just like github, I think. :)

[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

[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

[JonasFranzDEV]

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

[JonasFranzDEV]

@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

[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!

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

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

[lunny]

@JohnTheodore no people are working on this.

[xdevs23]

That's unfortunate

[xdevs23]

That's unfortunate

[JohnTheodore]

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

[JohnTheodore]

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