Integrate an OAuth2 provider #14

@bkcsoft commented on GitHub (Nov 4, 2016):

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

@bkcsoft commented on GitHub (Nov 4, 2016): Should this be integrated as "The" login-handler, or as an optional dependency? (i.e. build tag)

GiteaMirror commented

@tboerger commented on GitHub (Nov 4, 2016):

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

@tboerger commented on GitHub (Nov 4, 2016): I think we can always integrate it but add an option for admins to disable it

GiteaMirror commented

@lunny commented on GitHub (Nov 4, 2016):

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

@lunny commented on GitHub (Nov 4, 2016): No build tag but default is closed until admin open it.

GiteaMirror commented

@joubertredrat commented on GitHub (Nov 4, 2016):

Nice idea 👍

@joubertredrat commented on GitHub (Nov 4, 2016): Nice idea :+1:

GiteaMirror commented

@bkcsoft commented on GitHub (Nov 7, 2016):

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

@bkcsoft commented on GitHub (Nov 7, 2016): @tboerger @lunny I was more wondering if all Authentication should be handled by OAuth, therefore removing the old auth-module

GiteaMirror commented

@JohnTheodore commented on GitHub (May 2, 2017):

+1, this would be awesome!!!

@JohnTheodore commented on GitHub (May 2, 2017): +1, this would be awesome!!!

GiteaMirror commented

@femaref commented on GitHub (Jun 9, 2017):

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

@femaref commented on GitHub (Jun 9, 2017): is there an ETA for this? Would make life easier.

GiteaMirror commented

@lafriks commented on GitHub (Sep 4, 2017):

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

@lafriks commented on GitHub (Sep 4, 2017): I think this one could be good option to integrate into gitea - https://github.com/coreos/dex

GiteaMirror commented

@lunny commented on GitHub (Sep 5, 2017):

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

@lunny commented on GitHub (Sep 5, 2017): @lafriks Looks good, but it requires go1.8 I think.

GiteaMirror commented

@mikehaertl commented on GitHub (Sep 5, 2017):

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 commented on GitHub (Sep 5, 2017): 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?

GiteaMirror commented

@lafriks commented on GitHub (Sep 5, 2017):

@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 commented on GitHub (Sep 5, 2017): @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

GiteaMirror commented

@tboerger commented on GitHub (Sep 5, 2017):

JWT is a must have for drone integration

@tboerger commented on GitHub (Sep 5, 2017): JWT is a must have for drone integration

GiteaMirror commented

@ts468 commented on GitHub (Dec 15, 2017):

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 commented on GitHub (Dec 15, 2017): 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](https://nixos.org/hydra/), to fetch data over, e.g., the loopback interface.

GiteaMirror commented

@jonasfranz commented on GitHub (Mar 11, 2018):

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

@jonasfranz commented on GitHub (Mar 11, 2018): https://github.com/ory/fosite looks like a promising library to integrate this feature. It is used by hydra AFAIK.

GiteaMirror commented

@tboerger commented on GitHub (Mar 12, 2018):

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

@tboerger commented on GitHub (Mar 12, 2018): IMHO https://github.com/coreos/dex looks more promising

GiteaMirror commented

@bkcsoft commented on GitHub (Apr 28, 2018):

Migrating all existing users would be a PITA though 😂

@bkcsoft commented on GitHub (Apr 28, 2018): Migrating all existing users would be a PITA though :joy:

GiteaMirror commented

@aaronpk commented on GitHub (Jun 4, 2018):

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 commented on GitHub (Jun 4, 2018): It would be fantastic if Gitea were its own OAuth2 provider! In fact, [IndieAuth](https://www.w3.org/TR/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)

GiteaMirror commented

@tboerger commented on GitHub (Jun 4, 2018):

Sounds like it's comparable with openid connect.

@tboerger commented on GitHub (Jun 4, 2018): Sounds like it's comparable with openid connect.

GiteaMirror commented

@aaronpk commented on GitHub (Jun 4, 2018):

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 commented on GitHub (Jun 4, 2018): 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/)

GiteaMirror commented

@ekozan commented on GitHub (Jun 14, 2018):

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 commented on GitHub (Jun 14, 2018): 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

GiteaMirror commented

@bkcsoft commented on GitHub (Jun 15, 2018):

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

@bkcsoft commented on GitHub (Jun 15, 2018): @ekozan Mind linking to "OIDC" since I have no clue what that is :slightly_smiling_face:

GiteaMirror commented

@ekozan commented on GitHub (Jun 15, 2018):

@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 commented on GitHub (Jun 15, 2018): @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

GiteaMirror commented

@ekozan commented on GitHub (Jun 17, 2018):

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 commented on GitHub (Jun 17, 2018): 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

GiteaMirror commented

@tarelda commented on GitHub (Jun 25, 2018):

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 commented on GitHub (Jun 25, 2018): 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.

GiteaMirror commented

@lunny commented on GitHub (Jun 26, 2018):

@ekozan just like github, I think. :)

@lunny commented on GitHub (Jun 26, 2018): @ekozan just like github, I think. :)

GiteaMirror commented

@ekozan commented on GitHub (Jun 26, 2018):

@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 commented on GitHub (Jun 26, 2018): @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

GiteaMirror commented

@jonasfranz commented on GitHub (Jun 30, 2018):

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

@jonasfranz commented on GitHub (Jun 30, 2018): @ekozan You can create a seperate PR for the UI, this may improve the review speed.

GiteaMirror commented

@vtolstov commented on GitHub (Aug 13, 2018):

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

@vtolstov commented on GitHub (Aug 13, 2018): so, what library decided to use? i don't find any pr about oauth2 server in gitea

GiteaMirror commented

@xdevs23 commented on GitHub (Aug 13, 2018):

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

@xdevs23 commented on GitHub (Aug 13, 2018): I'm waiting for this one as well. Definitely looking forward to it!

GiteaMirror commented

@JohnTheodore commented on GitHub (Aug 22, 2018):

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

@JohnTheodore commented on GitHub (Aug 22, 2018): Is there a branch or PR related to this change? or we're still in the discussion phase.

GiteaMirror commented

@lunny commented on GitHub (Aug 23, 2018):

@JohnTheodore no people are working on this.

@lunny commented on GitHub (Aug 23, 2018): @JohnTheodore no people are working on this.

GiteaMirror commented

@xdevs23 commented on GitHub (Aug 23, 2018):

That's unfortunate

@xdevs23 commented on GitHub (Aug 23, 2018): That's unfortunate

GiteaMirror commented

@JohnTheodore commented on GitHub (Aug 24, 2018):

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

@JohnTheodore commented on GitHub (Aug 24, 2018): @ekozan mentioned a PR, I wasn't sure if that happened.

GiteaMirror commented

@JohnTheodore commented on GitHub (Sep 5, 2018):

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

@JohnTheodore commented on GitHub (Sep 5, 2018): @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.

GiteaMirror commented

@lunny commented on GitHub (Sep 6, 2018):

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.

@lunny commented on GitHub (Sep 6, 2018): 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.

GiteaMirror commented

@ekozan commented on GitHub (Oct 7, 2018):

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

@ekozan commented on GitHub (Oct 7, 2018): i'm totaly busy .... :/ i havent finish the work

GiteaMirror commented