Google is the first major identity provider to abandon OpenID 2.0 and jump aboard the bandwagon known as OpenID Connect.
OpenID 2.0 is user-centric: customers can use their choice of OpenID provider to sign in to any application that supports the protocol.
OpenID Connect, the “new and improved” specification from the OpenID foundation, is fundamentally different: applications now need to register themselves with their chosen subset of OpenID Connect providers (to obtain OAuth credentials), and users of that application can sign in using one of only that small subset of providers.
There are two specs that are sisters to OpenID Connect which introduce the ideas of Discovery and Dynamic Registration, by which applications can automatically obtain OAuth credentials for the user’s chosen provider. However, the specification makes it optional for providers to support Discovery and Dynamic Registration, and currently I’m not aware of any providers or client libraries that implement these protocols.
I loved OpenID 2.0. The movement to OpenID Connect takes the power away from both users and from application developers (not to mention the smaller identity providers) and gives it all to the biggest identity providers on the scene.
Google is the first major identity provider to drop support for OpenID 2.0. Application developers who chose to use OpenID 2.0 have a decision to make: do you force your users to switch to a different OpenID 2.0 provider, do you register your application with Google and provide support for OAuth + OpenID Connect, or do you entirely abandon SSO? The hard deadline is April 20 of this year.
Does your application use OpenID 2.0? What is your reaction to Google’s dropping support for the protocol? What are you going to do, if anything, to help transition those users who entrusted your site with Google OpenID 2.0?