Add support for federated OpenID-Connect logins

[strk]

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.

[strk]

Corresponding ticket in the library currently used for OIDC: markbates/goth#148

[colemickens]

Goth supports OpenID Connect now.

[strk]

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 ?

[colemickens]

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

Anyway, it also seems like Gitea already has OIDC login... #3644

Also, there's this issue, also from you, where you were using it? #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.

[meredrica]

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

[coolaj86]

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 #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

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

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

[deedubs]

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

[strk]

For testing, see simpleid/simpleid#30 (comment)

[colemickens]

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

[strk]

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 ?

[6543]

should be posible now

[strk]

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]

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)

[6543]

ok so the federated part is missing?

[strk]

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.