Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Gitea as an OpenID-2.0 provider #1310

Open
strk opened this issue Mar 17, 2017 · 19 comments · Fixed by #14139
Open

Gitea as an OpenID-2.0 provider #1310

strk opened this issue Mar 17, 2017 · 19 comments · Fixed by #14139
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented topic/authentication topic/federation type/feature Completely new functionality. Can only be merged if feature freeze is not active.

Comments

@strk
Copy link
Member

strk commented Mar 17, 2017

Now that OpenID instances can be configured to accept an OpenID login, it could be nice if they ccould also serve as OpenID providers so to build what would become the authentication layer of a federation of code repositories. See also #184
@lunny lunny added this to the 1.x.x milestone Mar 18, 2017
@lunny lunny added the type/feature Completely new functionality. Can only be merged if feature freeze is not active. label Mar 18, 2017
@cweiske

This comment has been minimized.

Sign in to view
@jhasse
Copy link

jhasse commented Jul 14, 2017

It isn't necessary, but it makes it easier as you don't have to create a traditional account on every Gitea instance where you want to open a pull request (and you don't have or don't want to use a different OpenID provider).

@bkcsoft

This comment has been minimized.

Sign in to view
@MaxG87
Copy link

MaxG87 commented Feb 11, 2019 •
edited
Loading

Albeit this thread is quiet for some time I want to add some points for the sake of the argument.

If you can setup your own gitea-instance you can setup your own OpenID provider.

And instantly you have to maintain two systems instead of one. Because a project decided not to contribute to infrastructure it partly relies on. And maintaining more systems in a self-hosting setting means much more opportunity to miss important updates.

Furthermore, at least for me, the condition of free, decentralised OpenID infrastructure seems to be quite bad. You can reuse the logins of your accounts at the usual tech giants, but only because someone hardcoded the support for them. I hardly know a service where you can use OpenID tokens from the provider of your choice. I also don't know providers of such tokens that could be used freely. All I know off is the possibility to integrate third-party-logins in your website for preselected third parties.

Long story short: OpenID needs more providers, otherwise Giteas OpenID feature cannot be used in a decentralised way. Gitea should be such a provider to reduce required mainenance efforts in self-hosting settings.

I really don't get why Gitea has to be a provider for everything

It is only about OpenID, isn't it? For me, this seems to be much less than everything.

@lunny
Copy link
Member

lunny commented Apr 21, 2019

Since Gitea now could be as OAuth2 provider, that's not too difficult.

@stale
Copy link

stale bot commented Jun 20, 2019

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.

@stale stale bot added the issue/stale label Jun 20, 2019
@lunny lunny added the issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented label Jun 20, 2019
@stale stale bot removed the issue/stale label Jun 20, 2019
@strk
Copy link
Member Author

strk commented Jun 20, 2019

I still think this is an important feature. Since Gitea does support OpenID-2.0, by acting as a provider would allow accessing all enabled Gitea instances via identity provided by your own. A big step toward federation.

@zeripath
Copy link
Contributor

If you put links to the specs in this issue anyone that's interested in building this functionality will have an easier time doing it.

@Mikaela Mikaela mentioned this issue Aug 6, 2019
Closed
@6543
Copy link
Member

6543 commented Nov 6, 2019

gitea now can act as openID provider - so close this issue?

@lunny
Copy link
Member

lunny commented Nov 7, 2019

Which PR resolved this?

@6543
Copy link
Member

6543 commented Nov 7, 2019

https://docs.gitea.io/en-us/oauth2-provider/?

@jolheiser
Copy link
Member

jolheiser commented Nov 7, 2019 •
edited
Loading

https://docs.gitea.io/en-us/oauth2-provider/?

OpenID is not OAuth2

For example, OAuth2 allows another service to access the Gitea API on your behalf, whereas OpenID would allow another service to treat your Gitea account as a valid account on their platform.
Apologies if that's not 100% correct, but it's my understanding of it on a high-level.

EDIT: This StackOverflow question answers it better than I did.

@philpraxis
Copy link

That would be great if Gitea can become OpenID Connect provider !
I don't know if I can ask, but let's go: Can someone familiar with the code explain the level of complexity (or days / weeks / months dev time) that such feature would need?

@ojohnny ojohnny mentioned this issue Dec 27, 2020
Merged
ojohnny added a commit to ojohnny/gitea that referenced this issue Dec 27, 2020
@ojohnny
Minimal OpenID Connect implementation
65dd5bf 
This is "minimal" in the sense that only the Authorization Code Flow
from OpenID Connect Core is implemented.  No discovery, no configuration
endpoint, and no user scope management.

OpenID Connect is an extension to the (already implemented) OAuth 2.0
protocol, and essentially an `id_token` JWT is added to the access token
endpoint response when using the Authorization Code Flow.  I also added
support for the "nonce" field since it is required to be used in the
id_token if the client decides to include it in its initial request.

In order to enable this extension an OAuth 2.0 scope containing
"openid" is needed. Other OAuth 2.0 requests should not be impacted by
this change.

This minimal implementation is enough to enable single sign-on (SSO)
for other sites, e.g. by using something like `mod_auth_openidc` to
only allow access to a CI server if a user has logged into Gitea.

Fixes: go-gitea#1310
lunny added a commit that referenced this issue Jan 1, 2021
@ojohnny @6543
@lunny @zeripath
Minimal OpenID Connect implementation (#14139)
a07e67d 
This is "minimal" in the sense that only the Authorization Code Flow
from OpenID Connect Core is implemented.  No discovery, no configuration
endpoint, and no user scope management.

OpenID Connect is an extension to the (already implemented) OAuth 2.0
protocol, and essentially an `id_token` JWT is added to the access token
endpoint response when using the Authorization Code Flow.  I also added
support for the "nonce" field since it is required to be used in the
id_token if the client decides to include it in its initial request.

In order to enable this extension an OAuth 2.0 scope containing
"openid" is needed. Other OAuth 2.0 requests should not be impacted by
this change.

This minimal implementation is enough to enable single sign-on (SSO)
for other sites, e.g. by using something like `mod_auth_openidc` to
only allow access to a CI server if a user has logged into Gitea.

Fixes: #1310

Co-authored-by: 6543 <[email protected]>
Co-authored-by: Lunny Xiao <[email protected]>
Co-authored-by: zeripath <[email protected]>
@lunny lunny modified the milestones: 1.x.x, 1.14.0 Jan 1, 2021
@strk
Copy link
Member Author

strk commented Jan 2, 2021

I think we want discovery for this ticket to be closed. Without discovery a Gitea instance could not be used as an identity provider for other Gitea instances. This ticket was about OpenID-2.0 for this reason (decentralization of identities)

@strk strk reopened this Jan 2, 2021
@lunny lunny removed this from the 1.14.0 milestone Jan 27, 2021
@lunny lunny added this to the 1.x.x milestone Jan 27, 2021
@6543 6543 closed this as completed Jun 27, 2021
@strk
Copy link
Member Author

strk commented Jun 28, 2021

Why was this closed ? There's no discovery implemented.

@strk strk reopened this Jun 28, 2021
@strk strk changed the title Gitea as an OpenID provider Gitea as an OpenID-2.0 provider Jun 28, 2021
@6543
Copy link
Member

6543 commented Jun 28, 2021

@strk I think so: https://try.gitea.io/.well-known/openid-configuration

@strk
Copy link
Member Author

strk commented Jun 28, 2021

But that's for oath, not OpenID-2.0, right ?

@6543
Copy link
Member

6543 commented Jun 28, 2021

hmm I thought it is for OpenID, to auto-discover things ...

@cweiske
Copy link
Contributor

cweiske commented Jun 28, 2021 •
edited
Loading

That is OpenID connect. OpenID 2 is something completely different :(

@snyk-bot snyk-bot mentioned this issue Jul 10, 2021
Open
@6543 6543 mentioned this issue Jan 11, 2022
Open
14 tasks
@lunny lunny removed this from the 1.x.x milestone Mar 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
issue/confirmed Issue has been reviewed and confirmed to be present or accepted to be implemented topic/authentication topic/federation type/feature Completely new functionality. Can only be merged if feature freeze is not active.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Minimal OpenID Connect implementation ojohnny/gitea
10 participants
@philpraxis @cweiske @jhasse @lunny @strk @zeripath @bkcsoft @MaxG87 @6543 @jolheiser