oauth2.0 / OpenIdConnect(OIDC)

OpenID Connect (OIDC) has become the leading standard for single sign-on and identity provision on the Internet for browser-based and mobile APPs. Tons of technical descriptions and both positive as well as critical statements can be found in the web.
 
OIDC is based on the OAuth2.0 authorization framework that is typically implemented using JSON Web Token (JWT).

JSON Web Token (JWT)
A JWT can be seen as an access key for HTTP-request from a client to a webserver without the need to store something session-specific on the webserver side (which fundamentally differentiates JWT from session cookies). In a JWT not only 'payload' is contained (Who was authorized/authenticated? For which service was the key issued? When was the key issued? How long is the key valid? ...), but also a digital signature (generated with a 'secret key') that makes it impossible to manipulate the JWT. A JWT is generated from the webserver typically in the course of a login-procedure and stored on client-site. Verification of the signature of a JWT does not require any database access and therefore is an effective way of authentication.

OAuth2.0
OAuth2.0 is a protocol that is used for delegated authorization i.e. a Resource-Owner(e.g. browser-user) wants to grant a Resource-Client permission to retrieve data from (one or different) Resource-Server on its behalf using an Auth-Server instead of resp. personal credentials (for any Resource-Server).
 
Some practical examples:
- a financial-App (Ressource-Client) shall display personal transactions of an App-User (Resource-Owner) at different banks (Resource-Servers) . Of course, the finance-app should not be allowed to do new transactions
- a multi-media app (Resource-Client) shall display personal video and image material of the App-user (Resource-Owner) from (one or different) cloud servers (Resource-Server)
- a social-media-app (e.g. Pinterest) shall access the friends list of the Facebook account(Resource-Server) of the app-user(Resource-Owner). Facebook provides an API that allows access via the Facebook Auth-Server
 
 
For ease of understanding, the principle process is presented below in a kind of "conversation” between the parties involved.
 
Ressource-Owner:
"Hello Ressource-Client! I would like to allow you to integrate my data from the Resource-Server that i mentioned in the request - without giving you my password there."

Ressource-Client:
Hmm. I am prepared for such requests. In the past, I have already agreed with the Auth-Server of the Resource-Server and exchanged a secret-key. So i redirect the Resource-Owner directly to the Auth-Server.

Auth-Server:
"Hello Ressource-Owner! Please authenticate yourself and confirm which access rights you want to give free."
...
Fine, I will redirect the Resource-Owner back to his Resource-Client with an authentication_code that I created. I know this way is not high-secure, but i am available for a subsequent check.
 
Resource-Client:
Hmm. Another request from a Resource-Owner along with an authentication_code. I can't remember what happened in the past, so i have to check directly on a secure channel with the Auth-Server whether the authentication_code is legal.

Auth-Server:
Hmm. Yes, with the authentication_code everything is fine. So that it doesn’t fall into the wrong hands i will delete it and return an access_token on a secure channel. This can be used as a 'key' on the Resource-Server.

Resource-Server:
Hmm. A Resource-Client is requesting data on behalf of the Resource-Owner. I am allowed to answer, because the access_token has not expired yet.
 
 
 

In the initialization phase, various configuration data must be generated and exchanged between the Resource-Server(s), Authentication-Server(s) and Client-Application(s) (e.g. before your client-application can use Google's OAuth2.0 authentication system, you must set up a project in the Google API Console):

  • the Authentication-Server and the Resource-Server must have set the same secret-key for encoding resp. decoding of JWT signatures
  • the Authentication-Server and the Client-application must have set the same redirect-uri of the Client-Application
  • the Resource-Server, the Client-Application and the Authentication-Server must have set the same client-id of the Client-Application
  • the Authentication-Server must (optionally) have the branding information and access-right selection will be displayed on the user-consent dialog
  • the Client-Application must have the authentication-URL of the Authentication-Server

An OAuth2.0-session then runs as follow:

  • a user of the Client-Application starts with the selection of his preferred Authentication-Service-Provider (e.g. Google, Facebook)
  • the Client-Application calls the authentication-URL of that Service (e.g. https://accounts.google.com/o/oauth2/v2/auth?scope=openid&redirect_uri=<client_callback_url>).
  • the Authentication-Server opens a dialog where the credentials of the user-account at the Authentication-Server are requested (typically a recent prior verification spares this manual interaction)
  • optionally the user can confirm a selection of specific access-rights for the Client-Application via an additional consent-dialog
  • the Authentication-Server calls the redirect-URL of the Client-Application (parameterized with an authentication code i.e. <client_callback_url>?code=<authentication-code>) (Front-Channel)
  • the Client-Application starts a further HTTP-POST-request (Back-Channel) to the Authentication-Server incl. the received authorization code in the HTTP-POST-body (Back-Channel)
  • the Authentication-Server returns a signed JWT in the HTTP-POST-result
  • the JWT can be used with further HTTP-requests from Client-Application to Resource-Server (in the Bearer) until expiration (a refresh is possible)
  • each time the Ressource-Server decodes the signature of a received JWT and checks integrity

OpenID Connect (OIDC)

OIDC is an authentication layer on top of OAuth2.0, which allows clients to verify the identity of an end-user and obtain basic profile information about the end-user via a RESTful HTTP API. In addition to the Access- and Refresh-tokens known from OAuth2.0, the ID-token is specified and typically used during log-in.

Controversy

In addition to the above mentioned advantages, OAuth2.0 / OIDC also has enormous disadvantages that caused lead developers to leave the project. In the case of disputes, economic interests had been placed above security aspects. The standard is more like a complex framework, and for its safe implementation, developers need to have a high level of expertise. The biggest weakness is in the actual implementation. Google and Facebook dominate the market for Authentication-Servers. The main reason for this lies in the fact that on the part of the Client-Applications and Resource-Servers, the support of a supported Authentication-Server always requires individual effort.