Implementing OpenID Connect for sopher.io
OpenID Connect is an identity layer on top of OAuth 2.0. Its main purpose is to ease Single Sign-On (SSO) implementations across different platforms and devices. It is currently widely deployed as “Login with Google / Facebook / Twitter” buttons on all sorts of web sites.
At sopher.io, we want sopher identities to be as useful as possible. So we decided to implement the OpenID Connect authorization flow, ultimately offering the “Login with sopher.io” button to third-party web sites.
OpenID Connect defines three types of flows that can be used by a Relying Party (RP) to perform user authentication at an OpenID Connect Provider (OP):
Code Flow
The Code Flow authenticates the user at his identity provider, e.g., Google, and redirects back with an authorization code. In a second step this code is used to obtain identity and access tokens. The second step takes place via server-to-server communication with the token end-point at the identity provider.
Implicit Flow
The Implicit Flow works without server-to-server communication. The identity provider directly redirects with identity and access tokens included in the fragment of the redirect URI. No backend is needed on the client side. At sopher.io we use this flow to connect to cloud storage providers.
Hybrid Flow
The third flow is a mixture of the Code Flow and the Implicit Flow called the Hybrid Flow.
At sopher.io profiles are hosted by the users themselves. We do not operate any servers to host user data and cannot provide a token end point on our side. This renders the code flow infeasible for us. Additionally we cannot verify users’ identities since we simply do not store anything about them.
The solution to these problems is actually part of the OpenID Connect specification: The Self-Issued Identity Provider. In combination with the Implicit Flow we can offer a fully compliant OpenID Connect implementation for sopher.io accounts.
Self-Issued Identity Provider
A Self-Issued Identity Provider is an entity that cryptographically asserts its identity. It does so by signing the fingerprint of its public key using a signed OpenID Connect id token including the fingerprint and the public key. At first login the RP stores the fingerprint of the public key as the id of the entity. At subsequent logins the RP validates the identity token using the public key included in the id token. How does sopher.io come into play?
The registration attribute of the OpenID Connect Self-Issued Identity Provider request is meant to provide information about the RP such as name, logo, or policy links. We use this field to transmit the client id token that a sopher app obtains upon registration. A sopher.io account can verify the identity of the RP as well as inferring name, logo, and origin information.
