Why to use OpenID Connect?

OpenID Connect is easier to integrate than SAML, and it can work with a wider variety of apps. Following are its main features : 

1.Easily consumed identity tokens

Client apps receive the user’s identity encoded in a secure JSON Web Token (JWT) called the ID token. JWTs are elegant and portable and support a range of signature and encryption algorithms.

2.The OAuth 2.0 protocol

Clients use OAuth 2.0 flows to obtain ID tokens, which work with web apps as well as native mobile apps. OAuth 2.0 also means that you have a single protocol for authentication and authorization (obtaining access tokens).

3.Simplicity with capability

OpenID Connect is simple enough to integrate with basic apps, while also offering features and security options that can meet demanding enterprise requirements.

OpenID Connect supports the following authentication flows:

• The Implicit Flow is required for apps that have no “back end” logic on the web server, like a Javascript app. Everything that is passed between the app or site and the Identity provider can be viewed using browser development tools.
• The Authentication (or Basic) Flow is designed for apps that have a back end that can communicate with the IdP away from prying eyes.
• The Resource Owner Password Grant does not have an login UI and is useful when access to a web browser is not possible.
• The Client Credentials Grant is useful for machine to machine authorization.

Implicit Flow 

In this flow, a public/private key (JSON Web Key) scheme is used to encrypt or sign user details. When the client app is registered with the IdP (OneLogin), Client ID and a Client Secret is issued. In an Implicit flow, the client secret should never be exposed.

Scenario

1.Sam attempts to start a session with his client app and is redirected to the OpenId provider, passing in the Client ID, which is unique for that application.

2.OpenID provider authenticates and authorizes Sam for a particular application instance.

3.Sam's details are encoded by the OpenID Provider into an id_token (JWT) that contains user information (scopes) and signature (using RS256), which is passed to a preconfigured Redirect page on the web server.

4. Client app confirms the JWT id_token and confirms the signature using the public key. if everything is fine, a session is established for the user.

Although, everything is passed in the front end and the client app cannot be authenticated, so even if someone steal the public key and client id, the IdP has the proper information (the redirect URI for the intended client app and the private key) to use the public key and client ID correctly. The transaction is secure in the Implicit Flow. 

Authentication Flow

In this flow, rather than transmit the user details, the provider sends a special, one-time-use code that can be exchanged by the back-end web service for an OAuth access token. This exchange needs to include the client id and client secret in addition to the code, just like a traditional OAuth 2.0 flow. It is more secure than the Implicit flow, because tokens are not visible through the browser and the client app can also be authenticated.

Scenario

1.Sam attempts to start a session with his client app and is redirected to the OpenId Provider, passing in the client ID, which is unique for that application. 

2.OpenID provider authenticates and authorizes Sam for a particular application instance.

3. A one-time-use code is passed back to the web server using a predefined Redirect URI.

4.The web server passes the code, Client ID, Client Secret to the OpenID Provider's token endpoint, and the OpenID Provider validates the code and returns a 1 hour access token.

5. The web server uses the access token to get further details about the user (if necessary) and establishes a session for the user.