Forgejo's announcement is four paragraphs and every one of them is a date or a boundary. The removal: OpenID Authentication 2.0, the standard for authenticating users. The survivors: OpenID Connect and OAuth — the announcement says explicitly these are "unrelated technologies that remain supported," which is worth printing because the names collide and a busy operator reading "OpenID removed" could reasonably panic an OIDC-based Keycloak setup that does not need to leave.

The dates, as printed

| Install | Last release with OpenID 2.0 | Covered until | | --- | --- | --- | | 15 LTS line | Forgejo v15 (current LTS) | July 15, 2027 (v15 end-of-life) | | Stable line | Forgejo v17, then v18 | April 29, 2027 (v18 end-of-life) | | Remove in | Forgejo v19 | Removed March 25, 2027 (v19 scheduled) |

The reasoning lives in the project's own discussion — the announcement links it rather than burying it. Note the arithmetic if you run LTS: for the 15 LTS line, the announcement's wording is that v15 is the last release series supporting OpenID 2.0 — meaning within the 15 series the support runs to the branch's end-of-life on July 15, 2027, about four months past v19's removal. If you are still on OpenID 2.0 at that point, your next step is a branch jump anyway; make the auth switch before the branch jump, not inside it.

What OpenID 2.0 actually is

A 2005–2007 protocol where an identity provider vouches for "this URL is this person." It predates OAuth2-based OpenID Connect by seven years and has almost nothing in common with it — the confusion between the two is the main reason announcements like this start with "OpenID Connect... remain supported." If your forge federates logins through anything built in the last decade, you are on OIDC and this post is a five-minute read ending in "carry on." Check it, do not assume it: Admin panel → Authentication Sources → look for sources of type OpenID (not OAuth2, not OpenID Connect); or grep the config for [openid] with ENABLE_OPENID = true, and check user table rows whose login source is an OpenID source. The blast radius when it is non-zero is usually small and known by name: a handful of long-tenured accounts that authenticate against an old community portal's OpenID endpoint — the kind of integration that has quietly worked since before everyone's current day job.

The migration, before it is forced

OpenID 2.0 cannot be translated; the accounts re-federate. Forgejo speaks OIDC per authentication source, and every provider a community is likely running — Keycloak, Authelia, Authentik, Nextcloud, or a plain OIDC-issuer — serves it. The sequence that does not create a lockout:

  1. Add the OIDC source alongside the OpenID 2.0 source; do not touch the old one yet.
  2. Match identities: either users self-link the OIDC identity while signed in (the standard association flow) or an admin maps them; Forgejo keeps an external-identity table per source, so both paths end the same way.
  3. Test one pilot account end to end, then flip the OpenID 2.0 source to disabled-but-not-deleted so you keep the mapping visible while stragglers arrive.
  4. Delete it when the count of OpenID-2.0 logins is zero for a month, or at the latest before the box takes v19 — the removal deletes the codepath, so an unmigrated user at v19 does not get a warning page, they get a broken leg.

None of this is urgent in November 2026 and none of it should be, which is the point of an announcement like this one: v19 is five months out, the LTS leg runs eight and a half more months past that, and the whole thing fits inside one planning calendar. It is the contrast with the release cadence two weeks ago — 16.0's support ending three days after its last security fix, reported here — that makes it worth writing down: when a project prints its deprecation dates, print the check into your runbook the same week it ships, and the deadline never becomes a surprise. Forgejo did the operator's homework for them here. All that is left is the one table row above, translated into a calendar entry.