Add support for federated OpenID-Connect logins #527

Open
opened 2025-11-02 03:26:47 -06:00 by GiteaMirror · 17 comments
Owner

Originally created by @strk on GitHub (Mar 17, 2017).

OpenID-Connect is already supported via the OAuth2 LoginSource, this ticket is to add support for the federated features of the spec: http://openid.net/specs/openid-connect-federation-1_0.html

NOTE: federated OpenID-2.0 is already supported (#618)
See #1010 for some previous discussion about OpenID-Connect and federation.

Originally created by @strk on GitHub (Mar 17, 2017). OpenID-Connect is already supported via the OAuth2 LoginSource, this ticket is to add support for the federated features of the spec: http://openid.net/specs/openid-connect-federation-1_0.html NOTE: federated OpenID-2.0 is already supported (#618) See #1010 for some previous discussion about OpenID-Connect and federation.
Author
Owner

@strk commented on GitHub (Mar 17, 2017):

Corresponding ticket in the library currently used for OIDC: https://github.com/markbates/goth/issues/148

@strk commented on GitHub (Mar 17, 2017): Corresponding ticket in the library currently used for OIDC: https://github.com/markbates/goth/issues/148
Author
Owner

@colemickens commented on GitHub (Jun 22, 2018):

Goth supports OpenID Connect now.

@colemickens commented on GitHub (Jun 22, 2018): Goth supports OpenID Connect now.
Author
Owner

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

Since which version @colemickens ? What would it take to make use of it from Gitea ? Just update to current master of Goth ? Do you have an OpenID-Connect provider to test an eventual implementation against ?

@strk commented on GitHub (Jun 26, 2018): Since which version @colemickens ? What would it take to make use of it from Gitea ? Just update to current master of Goth ? Do you have an OpenID-Connect provider to test an eventual implementation against ?
Author
Owner

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

It looks like Goth supported it since before you opened this issue, actually, from what I can tell: https://github.com/markbates/goth/pull/127

Anyway, it also seems like Gitea already has OIDC login... https://github.com/go-gitea/gitea/issues/3644

Also, there's this issue, also from you, where you were using it? https://github.com/go-gitea/gitea/issues/2100

I would be testing against Dex. I haven't stood up Gitea yet, might be a while before I make it back around to.

@colemickens commented on GitHub (Jun 26, 2018): It looks like Goth supported it since before you opened this issue, actually, from what I can tell: https://github.com/markbates/goth/pull/127 Anyway, it also seems like Gitea already has OIDC login... https://github.com/go-gitea/gitea/issues/3644 Also, there's this issue, also from you, where you were using it? https://github.com/go-gitea/gitea/issues/2100 I would be testing against Dex. I haven't stood up Gitea yet, might be a while before I make it back around to.
Author
Owner

@meredrica commented on GitHub (Oct 6, 2018):

Any news on this? Gitea looks really nice but not having SSO is a deal breaker for me :(

@meredrica commented on GitHub (Oct 6, 2018): Any news on this? Gitea looks really nice but not having SSO is a deal breaker for me :(
Author
Owner

@coolaj86 commented on GitHub (Oct 6, 2018):

This is something that I am working on personally and I'm trying to work slowly and with distinct commits so that it can come into mainline.

Check out https://github.com/go-gitea/gitea/pull/5029 if you're interested (just ux and bug fixes around the existing implementation so far). I also have instructions (in the issue) for giving my branch a test try if you'd like.

cc/ @meredrica

@coolaj86 commented on GitHub (Oct 6, 2018): This is something that I am working on personally and I'm trying to work slowly and with distinct commits so that it can come into mainline. Check out https://github.com/go-gitea/gitea/pull/5029 if you're interested (just ux and bug fixes around the existing implementation so far). I also have instructions (in the issue) for giving my branch a test try if you'd like. cc/ @meredrica
Author
Owner

@stale[bot] commented on GitHub (Jan 7, 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[bot] commented on GitHub (Jan 7, 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.
Author
Owner

@stale[bot] commented on GitHub (Mar 8, 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[bot] commented on GitHub (Mar 8, 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.
Author
Owner

@deedubs commented on GitHub (Mar 26, 2019):

Let me know if you need any help! Even if just testing I have a keycloak OIDC setup I can use to verify it.

@deedubs commented on GitHub (Mar 26, 2019): Let me know if you need any help! Even if just testing I have a keycloak OIDC setup I can use to verify it.
Author
Owner

@strk commented on GitHub (May 28, 2019):

For testing, see https://github.com/simpleid/simpleid/issues/30#issuecomment-496359846

@strk commented on GitHub (May 28, 2019): For testing, see https://github.com/simpleid/simpleid/issues/30#issuecomment-496359846
Author
Owner

@colemickens commented on GitHub (May 28, 2019):

I don't understand. The Discovery protocol is provided by the server and consumed by the client. AFAICT that does not implement OpenID Connect (edit, it looks like it implements OIDC, but I don't really like OIDC without Discovery).

Alternatively, https://github.com/dexidp/dex is an OpenID Connect identity provider (broker) that is easy to self-host, and it allows self-registration of clients, supports Discovery, it also can trivial chain into other authentication providers that don't allow self-registration. It's commonly used in "cloud-native" deployments, in conjunction with Go services and often containerized solutions. It would very likely be a good fit to use with Gitea. (edit, and is itself written in Go).

@colemickens commented on GitHub (May 28, 2019): I don't understand. The Discovery protocol is provided by the server and consumed by the client. AFAICT that does not implement OpenID Connect (edit, it looks like it implements OIDC, but I don't really like OIDC without Discovery). Alternatively, [https://github.com/dexidp/dex](Dex) is an OpenID Connect identity provider (broker) that is easy to self-host, and it allows self-registration of clients, supports Discovery, it also can trivial chain into other authentication providers that don't allow self-registration. It's commonly used in "cloud-native" deployments, in conjunction with Go services and often containerized solutions. It would very likely be a good fit to use with Gitea. (edit, and is itself written in Go).
Author
Owner

@strk commented on GitHub (May 29, 2019):

What is that you don't understand @colemickens ? The issue here is being able to allow people to just provide an arbitrary URI as an authentication mean...
Have you tried doing that with #5029 ?

@strk commented on GitHub (May 29, 2019): What is that you don't understand @colemickens ? The issue here is being able to allow people to just provide an arbitrary URI as an authentication mean... Have you tried doing that with #5029 ?
Author
Owner

@6543 commented on GitHub (Jun 27, 2021):

should be posible now

@6543 commented on GitHub (Jun 27, 2021): should be posible now
Author
Owner

@strk commented on GitHub (Jun 28, 2021):

Possible how ? Is there an example of such self-identity provision ?
BTW, I see OpenID-2.0 login was disabled on https://try.gitea.io/user/login -- was that intentional ? At the moment I've no way to even try that

@strk commented on GitHub (Jun 28, 2021): Possible how ? Is there an example of such self-identity provision ? BTW, I see OpenID-2.0 login was disabled on https://try.gitea.io/user/login -- was that intentional ? At the moment I've no way to even try that
Author
Owner

@strk commented on GitHub (Jun 28, 2021):

For reference: https://gitea.com/user/login still has OpenID support active, which shows Gitea-1.15 still supports that (good!)
I still don't see any online proof of "federated OpenID-Connect logins" (ie: I enter my own url, as a user, to prove my identity)

@strk commented on GitHub (Jun 28, 2021): For reference: https://gitea.com/user/login still has OpenID support active, which shows Gitea-1.15 still supports that (good!) I still don't see any online proof of "federated OpenID-Connect logins" (ie: I enter my own url, as a user, to prove my identity)
Author
Owner

@6543 commented on GitHub (Jun 28, 2021):

ok so the federated part is missing?

@6543 commented on GitHub (Jun 28, 2021): ok so the **federated** part is missing?
Author
Owner

@strk commented on GitHub (Jun 28, 2021):

Yes.
The goal is to be able to log into a Gitea instance by passing an arbitrary URL (either accepted or not based on some whitelist/blacklist eventually). Gitea would then delegate authenticating the user to a service discovered from the given URL.

@strk commented on GitHub (Jun 28, 2021): Yes. The goal is to be able to log into a Gitea instance by passing an arbitrary URL (either accepted or not based on some whitelist/blacklist eventually). Gitea would then delegate authenticating the user to a service discovered from the given URL.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#527