WHY OPENID CONNECT ISN’T THE IDENTITY FEDERATION SOLUTION YOU’RE LOOKING FOR
Recently several clients have approached us to request our assistance in implementing so-called “social login” solutions, whereby a user is able to authenticate themselves by using their personal Facebook, LinkedIn or Google account. With the advent of OpenID Connect in 2014, we firmly believed that this could easily be achieved via a single standard integration pattern and associated configuration information for each social network the client wished to make use of. However, when we began to look deeper, we realized that there are very few companies today which offer OIDC authentication services. This lack of adoption of the standard, particularly by companies such as Facebook, LinkedIn and Twitter is unfortunate and results in the need to develop custom integrations for each social network.
THE OIDC STANDARD
OpenID Connect is an authentication standard which is maintained and controlled by the OpenID Foundation. Released in 2014, OIDC is built on top of the OAuth 2 and JWT standards.
OIDC provides identity information in the form of a JWT and uses OAuth 2 scopes to easily specify required identity information. OIDC defines 5 “scopes” specific to the standard: openid, profile, email, address and phone. Since OIDC builds on top of OAuth 2, the “openid” scope is used to tell the receiver that this request is an OIDC request rather than a standard OAuth 2 request. The other 4 scopes are short-hand ways to ask for the most commonly requested claim information to be returned in the identity token. OIDC also restricts itself to defining only 3 methods for performing the authentication process and obtaining identity information or “Flows”: Authorization Code, Implicit and Hybrid.
OIDC PROVIDERS
At the time of writing (August 2017), there are only six companies (Google, Microsoft, Yahoo, PayPal, Amazon and SalesForce) who offer the possibility to authenticate users via OIDC, and of those, the only one which we would consider to be a “social media” company is Google.
SOCIAL NETWORK APPROACHES
In order to get a user’s identity from Facebook, a user must first be authenticated by Facebook. Facebook does not support OIDC, relying solely on OAuth2. The authentication process can be initiated using the OAuth2 “Authorization Code Flow” or the “Implicit Flow”, after which the access token returned to the requestor by Facebook can be used to access the https://graph.facebook.com/me service. The service will return information about the user referenced in the supplied access token. Any user with a valid access token can query the /me service to retrieve information from that token, no specific scopes are required. Access tokens are not bearer tokens and must be supplied to Facebook’s API via an HTTP request parameter called “access_token”.
In order to get a user’s identity from LinkedIn, a user must first be authenticated by LinkedIn. LinkedIn does not support OIDC, relying solely on OAuth2. The authentication process can only be initiated using the OAuth2 “Authorization Code Flow”, after which the access token returned to the requestor by LinkedIn can be used to access the https://api.linkedin.com/v1/people/~ service. The service will return information about the user referenced in the supplied access token. In order to be able to utilise this service, a valid access token containing a scope permitting access to at least the basic profile of a user, for example scope “r_basicprofile”, is required. Access tokens are bearer tokens and must be supplied to LinkedIn’s API via the HTTP Header “Authorization” supplying the access token as a “Bearer” token.
In order to get a user’s identity from Twitter, a user must first be authenticated by Twitter. Twitter does not support OIDC and does not support the latest version of the OAuth standard, perhaps showing its age, Twitter relies on OAuth 1a. The authentication process is initiated using the OAuth 1a “three-legged flow”, after which the access token returned to the requestor by Twitter can be used to access the https://api.twitter.com/1.1/account/verify_credentials.json service. The service will return information about the user referenced in the supplied access token. Any user with a valid access token can query the /account/verify_credentials service. Access tokens are bearer tokens and must be supplied to Twitter’s API via the HTTP Header “Authorization” supplying the access token as a “Bearer” token.
SUMMARY
Given that the goal of social media companies is to provide third parties with easy access to their API, it was not surprising to find that all of the social networks have adopted a standards based approach to API Management. The lack of support for an identity management standard can be understood when one realises that there is no real business advantage for these companies to become identity providers to third parties. Furthermore, for organisations who wish to extend their identity solution to include login via social networks, each of the social networks already do have a solution through the use of their own APIs. Finally, the cost of a custom integration for a given social network in order to obtain identity information is not born by that social network. Consequently, we do not believe that this situation is likely to change unless such a move would represent a competitive advantage for a social network.
