Summary

The deadline was Google's; the account was the site's

When Google welcomed OpenID Connect in February 2014, it also announced an expiry date for the old sign-in route. OpenID 2.0 support would stop on 20 April 2015. Developers could build on the new standard or use Google's sign-in tools. That gave sites more than a year of notice. It also made a technical migration a business deadline: a site whose users entered through Google had to change the door before Google removed the old hinge.

The old door had left something valuable behind. A relying site may have stored a user's verified OpenID 2.0 Claimed Identifier as the key to a local account. Orders, saved work, membership or settings would hang from that key. OpenID Connect represents identity differently, by the pair of provider issuer and subject. A successful new login therefore supplies a new identifier; it does not by itself tell the site which old ledger row to open. Replacing a sign-in button without migrating the account key could create a second, empty account for the same person. Joining the wrong keys could open somebody else's existing account.

Google repeated the clock in its 20 March 2015 reminder. ClientLogin, OAuth 1.0, AuthSub and OpenID 2.0 were due to shut down on 20 April. The company warned that applications left on those protocols would lose their ability to connect with Google, perhaps including sign-in, until they migrated. The notice was not a report of how many users suffered an outage. It was a clear statement of who controlled the old authentication endpoint's final day.

Four days separated final approval from the cutover

On 16 April 2015, OpenID Foundation members approved the final OpenID 2.0-to-OpenID Connect migration specification. The recorded vote was 28 in favour, none against and four abstentions. Four calendar days remained before Google's stated stop date. The interval was not the whole time available to developers: Google had announced its plan in 2014, and the final specification itself compares its rules with a Google migration guide dated June 2014. What arrived four days before the switch was the finished common method for proving the link between old and new identities.

The specification's introduction names the mismatch. OpenID 2.0 had a verified Claimed Identifier. OpenID Connect uses an issuer-and-subject pair. The relying party asks the new provider for both by adding the openid2 scope. If an old identifier exists for that user, the provider returns it as openid2_id in an ID Token. The site validates the token as an OpenID Connect token. Only then can it ask whether the provider making the new assertion has authority over the old identifier it claims to carry.

That last question is the gate. Under the final specification, a relying party can use a constrained same-authority case, or fetch the old identifier with an Accept: application/json request and compare the returned iss exactly with the issuer in the ID Token. The specification also describes a separate path for XRI identifiers. If those authority checks fail, the old identifier cannot be accepted for linking. Once the association is verified, the relying party should connect its existing OpenID 2.0 account to the new OpenID Connect identifier. The crucial operation happens in the site's account ledger, where the next successful login will point.

The specification's Appendix B reads like an argument about what that gate should say. It records that Google's June 2014 guide used openid.realm where the final standard chose openid2_realm, and openid_id where the standard chose openid2_id. It also says the guide did not perform the relying-party or old-identifier authority verification described in the final text. Those are the specification authors' documented comparisons with that guide, not a measurement of every Google deployment. They show why a common standard had work to do beyond repeating Google's migration instructions.

The sources do not count completed site migrations or identify sites where a wrong account was linked. A site's migration log and account-binding tests would show those outcomes. The dated records still expose the design choice: the platform could end an old sign-in protocol on schedule; each relying site had to decide whether a new credential deserved access to an old account.