No OpenID login is available | Federated login #142

diogo commented 2020年03月07日 14:21:03 +01:00

Could you please consider enabling this function in CodeBerg? It would make the adoption of this platform easier.

It bothers many users that they have to enter a full form of personal information in order to just file a bug or make a feature request. Even when it's to contribute with a Merge Request, many rather just mail me the patches.

OpenID support can easily fix this and support is available in Gitea.

Kind regards,

Could you please consider enabling this function in CodeBerg? It would make the adoption of this platform easier. It bothers many users that they have to enter a full form of personal information in order to just file a bug or make a feature request. Even when it's to contribute with a Merge Request, many rather just mail me the patches. OpenID support can easily fix this and support is available in Gitea. Kind regards,

Ghost commented 2020年03月07日 15:49:59 +01:00

It bothers many users that they have to enter a full form of personal information in order to just file a bug or make a feature request. Even when it's to contribute with a Merge Request, many rather just mail me the patches.

Just use disposable email address and fake name.

> It bothers many users that they have to enter a full form of personal information in order to just file a bug or make a feature request. Even when it's to contribute with a Merge Request, many rather just mail me the patches. Just use disposable email address and fake name.

diogo commented 2020年03月07日 16:43:37 +01:00

Ghost, that's not what I meant. These contributors aren't trying to stay anonymous, they just don't want to have to create one more account in yet another git host. This really is a request to add OpenID functionality in this website...

Ghost, that's not what I meant. These contributors aren't trying to stay anonymous, they just don't want to have to create one more account in yet another git host. This really is a request to add OpenID functionality in this website...

hw commented 2020年03月07日 17:44:36 +01:00

they just don't want to have to create one more account in yet another git host

that's exactly the point of alternative git hosting, that users like it and come there ;)

If there is nothing wrong with "the other (previous) git host", there would be no need for this platform.

Also please bear in mind that users would still have to confirm their email and set up authentification credential/u2f, as OpenID is by design susceptible to phishing, tracking, hijacking and privacy attacks unless a direct login is established after the initial handshake (short outline in the wikipedia article).

> they just don't want to have to create one more account in yet another git host that's exactly the point of alternative git hosting, that users like it and come there ;) If there is nothing wrong with "the other (previous) git host", there would be no need for this platform. Also please bear in mind that users would still have to confirm their email and set up authentification credential/u2f, as OpenID is by design susceptible to phishing, tracking, hijacking and privacy attacks unless a direct login is established after the initial handshake (short outline in the wikipedia article).

diogo commented 2020年03月07日 19:09:10 +01:00

If there is nothing wrong with "the other (previous) git host", there would be no need for this platform.

But, @hw, users might enjoy gitlab and want to contribute on a project hosted in codeberg - it doesn't mean they think there's something wrong with GitLab. In the described scenario, they just would like to reduce the number of accounts they have to maintain around in order to contribute to the various different projects they support.

Also please bear in mind that users would still have to confirm their email and set up authentification credential/u2f, as OpenID is by design susceptible to phishing, tracking, hijacking and privacy attacks unless a direct login is established after the initial handshake (short outline in the wikipedia article).

The protocol had it struggles, as many did. It's fairly safe these days as long as it is properly implemented and, as you've noted, "a direct login is established after the initial handshake".

Anyway, if you feel something like OpenID goes against CodeBerg's ideals, I'm okay about it.

To give some context, I'm hosting GNU social at https://notabug.org/diogo/gnu-social after we had some issues with the canonical repository. Unfortunately, NotABug doesn't promote much technical support and lately has revealed a couple of instabilities, limitations and - ironically - bugs.

I was, therefore, studying the possibility of moving the current repository to another git host that aligns well with GNU social's community ideals.

> If there is nothing wrong with "the other (previous) git host", there would be no need for this platform. But, @hw, users might enjoy gitlab and want to contribute on a project hosted in codeberg - it doesn't mean they think there's something wrong with GitLab. In the described scenario, they just would like to reduce the number of accounts they have to maintain around in order to contribute to the various different projects they support. > Also please bear in mind that users would still have to confirm their email and set up authentification credential/u2f, as OpenID is by design susceptible to phishing, tracking, hijacking and privacy attacks unless a direct login is established after the initial handshake (short outline in the wikipedia article). The protocol had it struggles, as many did. It's fairly safe these days as long as it is properly implemented and, as you've noted, "a direct login is established after the initial handshake". Anyway, if you feel something like OpenID goes against CodeBerg's ideals, I'm okay about it. To give some context, I'm hosting GNU social at https://notabug.org/diogo/gnu-social after we had some issues with the canonical repository. Unfortunately, NotABug doesn't promote much technical support and lately has revealed a couple of instabilities, limitations and - ironically - bugs. I was, therefore, studying the possibility of moving the current repository to another git host that aligns well with GNU social's community ideals.

hw commented 2020年03月07日 20:22:38 +01:00

I'm hosting GNU social

sounds like a perfect fit to Codeberg.org's aims! Welcome!

btw, maybe you want to have a chat with @ashimokawa : as it turned out, initial worries that users might hesitate to follow with issues, PRs and contributions turned out to be unjustified ;)

> I'm hosting GNU social sounds like a perfect fit to Codeberg.org's aims! Welcome! btw, maybe you want to have a chat with @ashimokawa : as it turned out, initial worries that users might hesitate to follow with issues, PRs and contributions turned out to be unjustified ;)

circlebuilder commented 2020年05月01日 22:09:09 +02:00

Merely tangential, but this ability - among others - is what ForgeFed is aiming to provide. Instead of a list of OAuth providers to support (github, gitlab, indieauth, etc.) it is then possible to access code forges with your fediverse account, or - if they support ForgeFed - with your existing forge account.

See: https://forgefed.peers.community/
Forum: https://talk.feneas.org/c/forgefed
Forges considered: https://notabug.org/peers/forgefed/issues/59
Gitea issue: https://github.com/go-gitea/gitea/issues/9045

Merely tangential, but this ability - among others - is what ForgeFed is aiming to provide. Instead of a list of OAuth providers to support (github, gitlab, indieauth, etc.) it is then possible to access code forges with your fediverse account, or - if they support ForgeFed - with your existing forge account. See: https://forgefed.peers.community/ Forum: https://talk.feneas.org/c/forgefed Forges considered: https://notabug.org/peers/forgefed/issues/59 Gitea issue: https://github.com/go-gitea/gitea/issues/9045

boud commented 2020年07月09日 04:26:24 +02:00

@circlebuilder Excellent! I was going to propose the Forgefed idea and I'm glad to not be able to claim any credit for the idea (well, I guess I independently rediscovered it...)

(削除) I'm wondering if this should count (削除ここまで) I think that ForgeFed should remain as a separate issue - which exists as issue #49, since it goes a lot beyond just logging in, it's about general social networking across independent git repository hosts.

It's not really an issue with Codeberg, though, it's rather something to bring to the attention of Codeberg users and developers/maintainers, some of whom might wish to contribute to Forgefed. To me this would seem to be a major step in helping people move off github/bitbucket/gitlab. Federations are generally better than centralised monopolies. (削除) Maybe it's just enough to add more discussion on this issue - 142 - for the moment. (削除ここまで)

@circlebuilder Excellent! I was going to propose the Forgefed idea and I'm glad to _not_ be able to claim any credit for the idea (well, I guess I independently rediscovered it...) ~~I'm wondering if this should count~~ I think that ForgeFed should remain as a separate issue - which exists as issue #49, since it goes a lot beyond just logging in, it's about general social networking across independent git repository hosts. It's not really an issue with Codeberg, though, it's rather something to bring to the attention of Codeberg users and developers/maintainers, some of whom might wish to contribute to Forgefed. To me this would seem to be a major step in helping people move off github/bitbucket/gitlab. Federations are generally better than centralised monopolies. ~~Maybe it's just enough to add more discussion on this issue - 142 - for the moment.~~

6543 commented 2021年08月29日 22:54:26 +02:00

should be fixed - feel free to reopen if not

should be fixed - feel free to reopen if not

diogo commented 2022年01月24日 17:37:05 +01:00

@6543 well, not exactly, OpenID login in gitea looks like this https://git.activitypub.dev/user/login/openid . And that isn't available in codeberg... But if it isn't going to be added, it doesn't make sense to reopen.

@6543 well, not exactly, OpenID login in gitea looks like this https://git.activitypub.dev/user/login/openid . And that isn't available in codeberg... But if it isn't going to be added, it doesn't make sense to reopen.

6543 commented 2022年08月09日 15:57:29 +02:00

It wont be enabled, we focus on federation via ForgeFed for now ...

https://forgefed.org

It wont be enabled, we focus on federation via ForgeFed for now ... https://forgefed.org

strk commented 2022年12月26日 18:53:25 +01:00

OpenID is federated identity. It was advertised (and properly works) as "the Internet Identity Layer". Why focus on something else to replace it when that works NOW and is well supported ? Please enable OpenID and make it possible now to login w/out creating a new account on any platforms (codeberg.org, github.com or gitlab.com)

OpenID *is* federated identity. It was advertised (and properly works) as "the Internet Identity Layer". Why focus on something else to replace it when that works NOW and is well supported ? Please enable OpenID and make it possible _now_ to login w/out creating a new account on any platforms (codeberg.org, github.com or gitlab.com)

boud commented 2022年12月26日 22:10:06 +01:00

OpenID is federated identity. It was advertised (and properly works) as "the Internet Identity Layer". Why focus on something else to replace it when that works NOW and is well supported ? Please enable OpenID and make it possible now to login w/out creating a new account on any platforms (codeberg.org, github.com or gitlab.com)

@strk See https://github.com/go-gitea/gitea/labels/theme%2Ffederation and https://github.com/go-gitea/gitea/issues/18240 . Currently at 18240, I see 5 out of 14 tasks ticked as "done". The two "auth" tasks are both concerned with OpenID. I'm sure that people working on this would be happy to see any merge requests that solve unclosed tasks.

Feel free to archive these various issue threads on GH (using Wayback or https://archive.today, or by better methods?), since there's no guarantee against Microsoft pulling the plug on Github (or selectively blocking parts of Github) anytime it wishes, especially since Forgefed is a fundamental threat to Microsoft/Github's quasi-monopoly. I guess that people active in the discussions could in principle reconstruct threads from their email boxes, but the time wasted would be huge.

> OpenID *is* federated identity. It was advertised (and properly works) as "the Internet Identity Layer". Why focus on something else to replace it when that works NOW and is well supported ? Please enable OpenID and make it possible _now_ to login w/out creating a new account on any platforms (codeberg.org, github.com or gitlab.com) @strk See https://github.com/go-gitea/gitea/labels/theme%2Ffederation and https://github.com/go-gitea/gitea/issues/18240 . Currently at 18240, I see 5 out of 14 tasks ticked as "done". The two "auth" tasks are both concerned with OpenID. I'm sure that people working on this would be happy to see any merge requests that solve unclosed tasks. Feel free to archive these various issue threads on GH (using Wayback or https://archive.today, or by better methods?), since there's no guarantee against Microsoft pulling the plug on Github (or selectively blocking parts of Github) anytime it wishes, especially since Forgefed is a fundamental threat to Microsoft/Github's quasi-monopoly. I guess that people active in the discussions could in principle reconstruct threads from their email boxes, but the time wasted would be huge.

xy commented 2022年12月27日 17:21:26 +01:00

It's a common mistake to confuse federated identity and forge federation.

Anyways, I don't see any reason why to not enable OpenID, especially since real forge federation won't be ready until another few months.

It's a [common mistake](https://a.exozy.me/posts/forge-federation-myths/#forge-federation-is-just-fancy-single-sign-on) to confuse federated identity and forge federation. Anyways, I don't see any reason why to not enable OpenID, especially since real forge federation won't be ready until another few months.

Gusted commented 2022年12月27日 17:22:58 +01:00

Alright, enough reason to re-open this. Already asked internally about this.

Alright, enough reason to re-open this. Already asked internally about this.

strk commented 2023年03月16日 20:43:22 +01:00

What's preventing you guys from enabling OpenID ? Can I help in any way ?

What's preventing you guys from enabling OpenID ? Can I help in any way ?

crystal commented 2023年03月16日 21:50:37 +01:00

I've had great difficulty in even testing the OpenID login functionality because there just aren't many services that actually support OpenID 2.0 (as a provider) anymore. It seems it's been largely deprecated in favor of OpenID Connect, which is essentially just a generic/universal implementation of OAuth2

I've had great difficulty in even testing the OpenID login functionality because there just aren't many services that actually support OpenID 2.0 (as a provider) anymore. It seems it's been largely deprecated in favor of OpenID Connect, which is essentially just a generic/universal implementation of OAuth2

strk commented 2023年03月16日 22:29:06 +01:00

@crystal how about just enabling it and ask us to test it ? We asked to enable it because we have OpenID-2.0 services (GNUSocial or what not).

I'm using simple-id, if you are curious.

OpenID Connect is documented to be "the new openid" but I've never seen a SINGLE service accepting an URL for authentication like OpenID-2.0 does. So I just can't really confirm OpenID-2.0 is deprecated because it provides a unique feature.

@crystal how about just enabling it and ask us to test it ? We asked to enable it because we have OpenID-2.0 services (GNUSocial or what not). I'm using simple-id, if you are curious. OpenID Connect is documented to be "the new openid" but I've never seen a SINGLE service accepting an URL for authentication like OpenID-2.0 does. So I just can't really confirm OpenID-2.0 is deprecated because it provides a unique feature.

Bubu commented 2023年03月17日 01:52:51 +01:00

I Was running simpleid in the past as well. The concept sounded great in 2009 or whenever that was. Unfortunately I think the only site that ever supported signing in with that was stackoverflow. When they stopped supporting openid, I discontinued my simpleid service. The protocol seems, idk, failed at this point, for whatever reasons.

There's a nonzero (support) cost with enabling this on the scale of Codeberg, so it needs to be well thought through if openid is worth it at this point. There are probably also good reasons why SO stopped offering it as an option.

Maybe a solution for the same use-case (bring your own IDP, basically) can be built on top of the more modern openid-connect (with dynamic client registration?). Forgefed will likely provide yet another different solution here.

Wherever you search for openid vs openid connect you find people stating that openid is deprecated. I don't think that's a good state to be in for an authentication protocol.

I Was running simpleid in the past as well. The concept sounded great in 2009 or whenever that was. Unfortunately I think the only site that ever supported signing in with that was stackoverflow. When they stopped supporting openid, I discontinued my simpleid service. The protocol seems, idk, failed at this point, for whatever reasons. There's a nonzero (support) cost with enabling this on the scale of Codeberg, so it needs to be well thought through if openid is worth it at this point. There are probably also good reasons why SO stopped offering it as an option. Maybe a solution for the same use-case (bring your own IDP, basically) can be built on top of the more modern openid-connect (with dynamic client registration?). Forgefed will likely provide yet another different solution here. Wherever you search for openid vs openid connect you find people stating that openid is deprecated. I don't think that's a good state to be in for an authentication protocol.

Bubu commented 2023年03月17日 01:57:02 +01:00

OpenID Connect is documented to be "the new openid" but I've never seen a SINGLE service accepting an URL for authentication like OpenID-2.0 does.

Openid connect doesn't work with urls for logins. (Those were often cited as the main reason openid failed to gain any significant adoption, users just didn't understand how an url can be a user-name)

It also supports different use-cases by default and is much more complex ... And still it is the official successor protocol. Seems like our usecase wasn't important enough to be of any consideration.

(Like I said above, maybe there's a way to rebuilt the use-case on top of oidc but more research required.)

> OpenID Connect is documented to be "the new openid" but I've never seen a SINGLE service accepting an URL for authentication like OpenID-2.0 does. Openid connect doesn't work with urls for logins. (Those were often cited as the main reason openid failed to gain any significant adoption, users just didn't understand how an url can be a user-name) It also supports different use-cases by default and is much more complex ... And still it is the official successor protocol. Seems like our usecase wasn't important enough to be of any consideration. (Like I said above, maybe there's a way to rebuilt the use-case on top of oidc but more research required.)

crystal commented 2023年03月17日 08:30:38 +01:00

@strk Things need to be tested before they are deployed to production. For the sanity of Codeberg's users, we shouldn't start chewing on random wires and hoping nothing breaks like they do at a certain San Francisco based tech firm.

I have tried deploying SimpleID, but I was unable to get it working properly with Forgejo. I would like to try again at some point but it's not high on my list of priorities, in part because deploying SimpleID was one of the only ways I could find to get an OpenID-2.0 account after a couple hours of research. All of the big tech firms who used to act as OpenID providers have sunsetted the feature. Every piece of open source software I looked at that acts as an OpenID provider is ancient and active development stagnated a long time ago. To me, it seems like the most realistic way to actually allow OpenID-2.0 logins from end users who don't wish to set up a server with SimpleID is for Forgejo to become an OpenID-2.0 provider, so that people could log in with their Forgejo account from a different instance.

On the topic of OpenID Connect, Forgejo's implementation works very nicely. Forgejo is an OIDC provider, and it works well for allowing people to log into various other services using their Forgejo account. Forgejo can also act as an OIDC client, allowing users to log in to Forgejo using their existing accounts on other services, the only real drawback being that the server's administrator must create an API token for the OIDC provider and configure Forgejo accordingly. The solution to this is something called OIDC Dynamic Client Registration, which would supposedly allow an OIDC client to self-register with the API of an OIDC provider in real-time when the user tries to log in. I have never seen this implemented in the wild (probably because big tech firms don't like it) but assuming that it does work, I think this is the direction we should be going with federated logins for Forgejo.

@strk Things need to be tested _before_ they are deployed to production. For the sanity of Codeberg's users, we shouldn't start chewing on random wires and hoping nothing breaks like they do at a certain San Francisco based tech firm. I have tried deploying SimpleID, but I was unable to get it working properly with Forgejo. I would like to try again at some point but it's not high on my list of priorities, in part because deploying SimpleID was one of the only ways I could find to _get_ an OpenID-2.0 account after a couple hours of research. All of the big tech firms who used to act as OpenID providers have sunsetted the feature. Every piece of open source software I looked at that acts as an OpenID provider is ancient and active development stagnated a long time ago. To me, it seems like the most realistic way to _actually_ allow OpenID-2.0 logins from end users who don't wish to set up a server with SimpleID is for Forgejo to become an OpenID-2.0 provider, so that people could log in with their Forgejo account from a different instance. On the topic of OpenID Connect, Forgejo's implementation works very nicely. Forgejo is an OIDC provider, and it works well for allowing people to log into various other services using their Forgejo account. Forgejo can also act as an OIDC client, allowing users to log in to Forgejo using their existing accounts on other services, the only real drawback being that the server's administrator must create an API token for the OIDC provider and configure Forgejo accordingly. The solution to this is something called OIDC Dynamic Client Registration, which would supposedly allow an OIDC client to self-register with the API of an OIDC provider in real-time when the user tries to log in. I have never seen this implemented in the wild (probably because big tech firms don't like it) but assuming that it does work, I think this is the direction we should be going with federated logins for Forgejo.

strk commented 2023年03月21日 23:06:11 +01:00

Optimum is the enemy of good. OpenID-2.0 works TODAY, it's implemented in Gitea, I have a provider, anyone with a GNUSocial or Friendica account have a provider (dunno which others). It's a single switch away.

Optimum is the enemy of good. OpenID-2.0 works TODAY, it's implemented in Gitea, I have a provider, anyone with a GNUSocial or Friendica account have a provider (dunno which others). It's a single switch away.

n0toose commented 2023年03月22日 11:34:04 +01:00

how about just enabling it and ask us to test it ?

Things need to be tested before they are deployed to production.

Well, we have a test instance.

> how about just enabling it and ask us to test it ? > Things need to be tested before they are deployed to production. Well, we have a test instance.

strk commented 2023年04月06日 15:28:33 +02:00

For the record, gitea.com (upstream Gitea) is allowing OpenID-2.0 logins:
https://gitea.com/user/login/openid

For the record, gitea.com (upstream Gitea) is allowing OpenID-2.0 logins: https://gitea.com/user/login/openid

n0toose commented 2023年04月07日 10:07:30 +02:00

For the record, gitea.com (upstream Gitea) is allowing OpenID-2.0 logins

Also provides certain examples of OpenID-2.0 providers.

This may get more relevant in the future, considering that many of us actively use Matrix: https://areweoidcyet.com/

Potential issue with supporting more login methods right now, not sure if this should be considered as a valid distraction: #985

> For the record, gitea.com (upstream Gitea) is allowing OpenID-2.0 logins Also provides certain examples of OpenID-2.0 providers. This may get more relevant in the future, considering that many of us actively use Matrix: https://areweoidcyet.com/ Potential issue with supporting more login methods right now, not sure if this should be considered as a valid distraction: https://codeberg.org/Codeberg/Community/issues/985

Bubu commented 2023年04月07日 11:33:11 +02:00

@n0toose don't confuse openid (the old standard) with oidc (where matrix, and everyone else, is going, based on OAuth 2).

@n0toose don't confuse openid (the old standard) with oidc (where matrix, and everyone else, is going, based on OAuth 2).

n0toose commented 2023年04月07日 12:44:17 +02:00

Sorry for not clarifying, was trying to talk about other login methods that may be desirable for users depending on decentralized platforms that may be perceived as not "reliable as GitHub/GitLab", which is why I saw that as "relevant". But you're right, expanding the scope in this ticket in the way that I did is probably not desirable.

Sorry for not clarifying, was trying to talk about other login methods that may be desirable for users depending on decentralized platforms that may be perceived as not "reliable as GitHub/GitLab", which is why I saw that as "relevant". But you're right, expanding the scope in this ticket in the way that I did is probably not desirable.

boud commented 2023年04月07日 14:22:43 +02:00

@Bubu In terms of ambiguity of terminology, on https://areweoidcyet.com I see strings including:

• "OpenID Connect"
• "OpenID Providers and Clients"
• "OpenID Providers"

and https://openid.net/connect says that "OpenID Connect [is] different [to] OpenID 2.0" (with the implication of "different" = "better" in the answer to the F.A. question).

(削除) When you say "where matrix, and everyone else, is going, based on OAuth", do you mean "where matrix, and everyone else, is going, based on the OAuth-2.0 protocol"? (削除ここまで) (done)

The openid.net FAQ seems to clarify the relations between things for people like me unfamiliar with the various protocols and software:

• the OpenID Connect and OpenID 2.0 protocols are architecturally similar
• OpenID 2.0 implementations "sometimes mysteriously refuse to interoperate"
• OAuth 2.0 is the "substrate" of OpenID Connect
• OAuth 2.0 outsources encryption to the web's TLS (https, ssl)
• OpenID Connect is better than OpenID 2.0 (per openid.net)
• OIDC = OpenID Connect

and looking at the 2023年09月13日 version of https://areweoidcyet.com it looks like

• Matrix implementation of OIDC is currently still quite incomplete (e.g. the Element Web client has none of the requirements implemented so far).

@Bubu In terms of ambiguity of terminology, on https://areweoidcyet.com I see strings including: * "OpenID Connect" * "OpenID Providers and Clients" * "OpenID Providers" and https://openid.net/connect says that "OpenID Connect [is] different [to] OpenID 2.0" (with the implication of "different" = "better" in the answer to the F.A. question). ~~When you say "where matrix, and everyone else, is going, based on OAuth", do you mean "where matrix, and everyone else, is going, based on the OAuth-2.0 protocol"?~~ _(done)_ The [openid.net FAQ](https://openid.net/developers/how-connect-works/) seems to clarify the relations between things for people like me unfamiliar with the various protocols and software: * the OpenID Connect and OpenID 2.0 protocols are architecturally similar * OpenID 2.0 implementations "sometimes mysteriously refuse to interoperate" * OAuth 2.0 is the "substrate" of OpenID Connect * OAuth 2.0 outsources encryption to the web's TLS (https, ssl) * OpenID Connect is better than OpenID 2.0 (per openid.net) * OIDC = OpenID Connect and looking at the 2023年09月13日 version of https://areweoidcyet.com it looks like * Matrix implementation of OIDC is currently still quite incomplete (e.g. the `Element Web` client has none of the requirements implemented so far).

Bubu commented 2023年04月07日 22:36:25 +02:00

When you say "where matrix, and everyone else, is going, based on OAuth", do you mean "where matrix, and everyone else, is going, based on the OAuth-2.0 protocol"?

Yes. edited my post for clarity.

> When you say "where matrix, and everyone else, is going, based on OAuth", do you mean "where matrix, and everyone else, is going, based on the OAuth-2.0 protocol"? > > Yes. edited my post for clarity.

strk commented 2023年04月09日 12:16:38 +02:00

For the record, gitea.com (upstream Gitea) is allowing OpenID-2.0 logins

Also provides certain examples of OpenID-2.0 providers.

What do you mean by that ? Is it the https://anne.me, bob.openid.org.cn or gnusocial.net/carry text in https://gitea.com/user/login/openid ?

That text is in Gitea (and Forgejo) itself, not anything specific to gitea.com deploy.

Interesting info about Matrix planning to become an OAuth-2.0 based identity provider, but until that happens, and until Gitea (or Forgejo) implement provider discovery toggling a variable in a config file seems very easy to me and with no problematic consequences that I can see.

> > For the record, gitea.com (upstream Gitea) is allowing OpenID-2.0 logins > > Also provides certain examples of OpenID-2.0 providers. What do you mean by that ? Is it the `https://anne.me, bob.openid.org.cn or gnusocial.net/carry` text in https://gitea.com/user/login/openid ? That text is in Gitea (and [Forgejo](https://codeberg.org/forgejo/forgejo/src/tag/v1.20.0-dev/options/locale/locale_en-US.ini#L358)) itself, not anything specific to gitea.com deploy. Interesting info about Matrix planning to become an OAuth-2.0 based identity provider, but until that happens, and until Gitea (or Forgejo) implement [provider discovery](https://github.com/matrix-org/matrix-spec-proposals/pull/2965) toggling a variable in a config file seems very easy to me and with no problematic consequences that I can see.

strk commented 2024年01月03日 20:19:50 +01:00

So is this ticket about OpenID-Connect or OpenID-2.0 ? I'm interested in OpenID-2.0 which is already available, should I file another ticket ? Is the original author of this one willing to change the title to clarify what it is about ?

So is this ticket about OpenID-Connect or OpenID-2.0 ? I'm interested in OpenID-2.0 which is already available, should I file another ticket ? Is the original author of this one willing to change the title to clarify what it is about ?

boud commented 2024年01月03日 23:22:14 +01:00

I'm not @diogo :). But if I understand things correctly, there's not much support for the old OpenID, so it would seem that the main question that makes sense in this thread is:

While waiting for OIDC/OAuth-2.0 implementation in ForgeJo to be sufficiently mature, should Codeberg enable OpenID-2.0, which apparently is an easy switch to make?

1. Arguments for No:
   1. OpenID-2.0 sometimes has mysterious interoperability problems
   2. OIDC appears to be a better long-term choice, so effort in enabling and checking (security flaws, bugs) OpenID-2.0 would be more of a waste of time and distraction than a benefit
2. Arguments for Yes:
   1. OpenID-2.0 works right now
   2. enabling OpenID-2.0 right now would make it more likely for people without Codeberg accounts to contribute merge requests (MRs), bug reports and other issues like feature requests

I'm not judging the strength of the arguments, just trying to list them.

I'm not @diogo :). But if I understand things correctly, there's not much support for the old OpenID, so it would seem that the main question that makes sense in this thread is: _While waiting for OIDC/OAuth-2.0 implementation in ForgeJo to be sufficiently mature, should Codeberg enable OpenID-2.0, which apparently is an easy switch to make?_ 1. Arguments for _No_: 1. OpenID-2.0 [sometimes has mysterious interoperability problems](https://openid.net/developers/how-connect-works) 1. OIDC appears to be a better long-term choice, so effort in enabling and checking (security flaws, bugs) OpenID-2.0 would be more of a waste of time and distraction than a benefit 1. Arguments for _Yes_: 1. OpenID-2.0 works right now 1. enabling OpenID-2.0 right now would make it more likely for people without Codeberg accounts to contribute merge requests (MRs), bug reports and other issues like feature requests I'm not judging the strength of the arguments, just trying to list them.

strk commented 2024年01月04日 10:36:31 +01:00

I've created a new more specific issue: #1398

I've created a new more specific issue: https://codeberg.org/Codeberg/Community/issues/1398

strk commented 2025年09月07日 20:30:31 +02:00

For the record: 5 years have gone and OpenID-2.0 sign-in is still disabled. It's just a configuration line to switch from OFF to ON, where should a ticket be filed to reach the hears of those who can turn that switch ?

For the record: 5 years have gone and OpenID-2.0 sign-in is still disabled. It's just a configuration line to switch from OFF to ON, where should a ticket be filed to reach the hears of those who can turn that switch ?

strk commented 2025年09月07日 20:45:04 +02:00

where should a ticket be filed to reach the hears of those who can turn that switch ?

Answering myself: Codeberg-Infrastructure/build-deploy-forgejo#178

> where should a ticket be filed to reach the hears of those who can turn that switch ? Answering myself: https://codeberg.org/Codeberg-Infrastructure/build-deploy-forgejo/pulls/178

Gusted commented 2025年09月07日 21:10:38 +02:00

There have been talks in Forgejo to deprecate OpenID-2.0 because it's effectively deprecated in favor of OIDC, I don't think Codeberg would do good to enable this. OIDC auto discovery is promising but not supported at the moment.

There have been talks in Forgejo to deprecate OpenID-2.0 because it's effectively deprecated in favor of OIDC, I don't think Codeberg would do good to enable this. OIDC auto discovery is promising but not supported at the moment.

strk commented 2025年09月08日 09:01:32 +02:00

Sane deprecation policies allow a period of overlap between old and new way to obtain the same result. In this case there's not even a new way yet so ...

Let's wait for that promise to be realized before even thinking of deprecating a well established and effectively working solution ?

Sane deprecation policies allow a period of overlap between old and new way to obtain the same result. In this case there's not even a new way yet so ... Let's wait for that promise to be realized before even thinking of deprecating a well established and effectively working solution ?

n0toose commented 2025年09月08日 09:22:07 +02:00

Who's going to bear the responsibility of reaching out to the people with OpenID-2.0 accounts so as to try and get them to convert their accounts into normal accounts at a later point?

Who's going to bear the responsibility of reaching out to the people with OpenID-2.0 accounts so as to try and get them to convert their accounts into normal accounts at a later point?

strk commented 2025年09月08日 09:27:23 +02:00

OpenID-2.0 accounts are already "normal accounts" (internal accounts), just with an additional way to login via OpenID.
This problem is rather with GitLab/GitHub accounts, see https://github.com/go-gitea/gitea/issues/1124

About the deprecation, I see that OpenID-2.0 sign in is still enabled in the "Try it now" showcase of forgejo: https://v12.next.forgejo.org/user/login - do you have a pointer to some public discussion about plans to deprecate it ?

OpenID-2.0 accounts are already "normal accounts" (internal accounts), just with an additional way to login via OpenID. This problem is rather with GitLab/GitHub accounts, see https://github.com/go-gitea/gitea/issues/1124 About the deprecation, I see that OpenID-2.0 sign in is still enabled in the "Try it now" showcase of forgejo: https://v12.next.forgejo.org/user/login - do you have a pointer to some public discussion about plans to deprecate it ?

Codeberg/Community