OpenID Connect (OIDC) 1.0

• Identity layer on top of OAuth 2.0
• It allows Relying Party (RP) to verify the identity of the End-User based on the authentication performed by an OAuth 2.0 Authorization Server (OP), as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner
• Uses REST/JSON message flows
• (Identity, Authentication) + OAuth 2.0 = OpenID Connect
• OpenID Connect is the third generation of OpenID technology (after OpenID and OpenID 2.0)
• developed in an OpenID Foundation working group
• also defines optional mechanisms for robust signing and encryption

Problem solved by OICD

• Authenticate without taking responsibility of storing/managing passwords
• Delicate authentication to third party OAuth 2.0 Authentication Server

Why use OICD?

• Interoperable
• Secure
• Ease of deployment
• Flexible
• IoT support
• Separation of concerns: Enabling Claims Providers to be distinct from Identity Providers

OAuth 2.0 vs OIDC

OICD vs SAML

Abstract OICD Workflow

1. The RP (Client) sends a request to the OpenID Provider (OP).
2. The OP authenticates the End-User and obtains authorization.
3. The OP responds with an ID Token and usually an Access Token.
4. The RP can send a request with the Access Token to the UserInfo Endpoint.
5. The UserInfo Endpoint returns Claims about the End-User.

OpenID Connect Roles

OICD as Provider (OP)

• OAuth 2.0 Authentication Servers implementing OpenID Connect are also referred to as OpenID Providers (OPs)
•  Provides endpoints such as
  • Authorization Endpoint: Performs authentication of the user using request parameters defined by OAuth 2.0 and additional parameters and parameter values defined by OpenID Connect. Returns an authorization code.
  • Token Endpoint: Issues an access_token, id_token and refresh_token to the RP
  • Introspection Endpoint: Used for determining the status of a current access_token (valid or invalid)
• 5 types
  • Basic OP
  • Implicit OP
  • Hybrid OP
  • Config OP
  • Dynamic OP

OICD as Relying Party (RP)

•  OAuth 2.0 Clients using OpenID Connect are also referred to as Relying Parties (RPs)
• Relying Party can obtains Authorization Endpoint and Token Endpoints from OICD provider  using  OpenID Connect Discovery
• 5 types
  • Basic RP
  • Implicit RP
  • Hybrid RP
  • Config RP
  • Dynamic RP

OpenID Connect Discovery 1.0

• Relying Party can obtain configuration information about the OpenID Provider, including its Authorization Endpoint and Token Endpoint locations using OICD Discovery 1.0

OpenID Connect Dynamic Client Registration 1.0

• Relying Party can obtain sufficient credentials and provided information needed to use the OpenID Provider using OICD dynamic client registration 1.0

OAuth 2.0 Flows

• Provides three flows

Authorization Code Flow

The Authorization Code Flow goes through the following steps.

1. Client prepares an Authentication Request containing the desired request parameters.
2. Client sends the request to the Authorization Server.
3. Authorization Server Authenticates the End-User.
4. Authorization Server obtains End-User Consent/Authorization.
5. Authorization Server sends the End-User back to the Client with an Authorization Code.
6. Client requests a response using the Authorization Code at the Token Endpoint.
7. Client receives a response that contains an ID Token and Access Token in the response body.
8. Client validates the ID token and retrieves the End-User’s Subject Identifier.

Implicit Flow

• OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint and neither the Token Endpoint nor an Authorization Code are used

The Implicit Flow follows the following steps:

1. Client prepares an Authentication Request containing the desired request parameters.
2. Client sends the request to the Authorization Server.
3. Authorization Server Authenticates the End-User.
4. Authorization Server obtains End-User Consent/Authorization.
5. Authorization Server sends the End-User back to the Client with an ID Token and, if requested, an Access Token.
6. Client validates the ID token and retrieves the End-User’s Subject Identifier.

Hybrid

• OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint

The Hybrid Flow follows the following steps:

1. Client prepares an Authentication Request containing the desired request parameters.
2. Client sends the request to the Authorization Server.
3. Authorization Server Authenticates the End-User.
4. Authorization Server obtains End-User Consent/Authorization.
5. Authorization Server sends the End-User back to the Client with an Authorization Code and, depending on the Response Type, one or more additional parameters.
6. Client requests a response using the Authorization Code at the Token Endpoint.
7. Client receives a response that contains an ID Token and Access Token in the response body.
8. Client validates the ID Token and retrieves the End-User’s Subject Identifier.

Privacy

• OpenID Connect identifies a set of personal attributes that can be exchanged between Identity Providers and the apps that use them, and includes an approval step so that users can consent (or deny) the sharing of this information.

Terminology

• Authentication: Process used to achieve sufficient confidence in the binding between the Entity and the presented Identity
• Authentication Request: OAuth 2.0 Authorization Request using extension parameters and scopes defined by OpenID Connect to request that the End-User be authenticated by the Authorization Server, which is an OpenID Connect Provider, to the Client, which is an OpenID Connect Relying Party
• Authentication Context: Information that the Relying Party can require before it makes an entitlement decision with respect to an authentication response. Such context can include, but is not limited to, the actual authentication method used or level of assurance such as entity authentication assurance level
• Authentication Context Class: Set of authentication methods or procedures that are considered to be equivalent to each other in a particular context
• Authentication Context Class Reference: Identifier for an Authentication Context Class
• Authorization Code Flow: OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint and all tokens are returned from the Token Endpoint
• Claim: Piece of information asserted about an Entity. Information asserted about a user, such as a first name or phone number
• Claim Type: Syntax used for representing a Claim Value. This specification defines Normal, Aggregated, and Distributed Claim Types
• Claims Provider: Server that can return Claims about an Entity
• Credential: Data presented as evidence of the right to use an identity or other resources
• End-User: Human participant
• Entity: Something that has a separate and distinct existence and that can be identified in a context. An End-User is one example of an Entity
• Essential Claim: Claim specified by the Client as being necessary to ensure a smooth authorization experience for the specific task requested by the End-User
• Hybrid Flow: OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint
• ID Token: JSON Web Token (JWT)  that contains Claims about the Authentication event. It MAY contain other Claims
• Identifier: Value that uniquely characterizes an Entity in a specific context
• Identity: Set of attributes related to an Entity
• Implicit Flow: OAuth 2.0 flow in which all tokens are returned from the Authorization Endpoint and neither the Token Endpoint nor an Authorization Code are used
• Issuer: Entity that issues a set of Claims.
• Issuer Identifier: Verifiable Identifier for an Issuer. An Issuer Identifier is a case sensitive URL using the https scheme that contains scheme, host, and optionally, port number and path components and no query or fragment components
• Message: Request or a response between an OpenID Relying Party and an OpenID Provider
• OpenID Provider (OP): OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User
• Request Object: JWT that contains a set of request parameters as its Claims
• Request URI: URL that references a resource containing a Request Object. The Request URI contents MUST be retrievable by the Authorization Server
• Pairwise Pseudonymous Identifier (PPID): Identifier that identifies the Entity to a Relying Party that cannot be correlated with the Entity’s PPID at another Relying Party
• Personally Identifiable Information (PII): Information that (a) can be used to identify the natural person to whom such information relates, or (b) is or might be directly or indirectly linked to a natural person to whom such information relates
• Relying Party (RP): OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider
• Sector Identifier: Host component of a URL used by the Relying Party’s organization that is an input to the computation of pairwise Subject Identifiers for that Relying Party
• Self-Issued OpenID Provider: Personal, self-hosted OpenID Provider that issues self-signed ID Tokens
• Subject Identifier: Locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client
• UserInfo Endpoint: Protected Resource that, when presented with an Access Token by the Client, returns authorized information about the End-User represented by the corresponding Authorization Grant. The UserInfo Endpoint URL MUST use the https scheme and MAY contain port, path, and query parameter components.ValidationProcess intended to establish the soundness or correctness of a construct
• Verification: Process intended to test or prove the truth or accuracy of a fact or value
• Voluntary Claim: Claim specified by the Client as being useful but not Essential for the specific task requested by the End-User.

Extra

• To verify google access token
  • https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=
• Google Client libraries  – to take care of many of the implementation details of authenticating users and gaining access to Google APIs. Authenticating users properly is important to their and your safety and security, and using well-debugged code written by others is generally a best practice – https://developers.google.com/identity/protocols/OpenIDConnect#libraries
• Google API scopes https://developers.google.com/identity/protocols/googlescopes
• OpenID Connect response sample from Google

{
  "stat": "ok",
  "profile": {
    "displayName": "xyz",
    "email": "xyz@gmail.com",
    "gender": "male",
    "googleUserId": "xyz",
    "identifier": "https://www.google.com/profiles/xyz",
    "name": {
      "familyName": "xyz",
      "formatted": "xyz",
      "givenName": "xyz"
    },
    "photo": "https://lh6.googleusercontent.com/-xyz/xyz/AAAAAAAAPIk/Ivgln2e27iY/photo.jpg?sz=50&sz=400",
    "preferredUsername": "xyz",
    "providerName": "Google+",
    "providerSpecifier": "googleplus",
    "provider_id": "114164066252810302501",
    "url": "https://plus.google.com/+xyz",
    "verifiedEmail": "xyz@gmail.com"
  },
  "accessCredentials": {
    "accessToken": "ya29.GlufBZGH9hZhqe60ij_YwJ4lSeAQeKexyzxyzxyzxyz",
    "clientId": "xyzxyz-xyzxyzxyzxyzxyz.apps.googleusercontent.com",
    "expires": 1523908723,
    "refreshToken": "1/QrxWKVPnVyxyzxyzxyzxyzxyzL4WbxCjrN5xwzXnQ",
    "scopes": "openid",
    "type": "openidconnect",
    "uid": "114164123456810302501"
  }
}

Resources

• http://openid.net/connect/OpenID Connect
• http://openid.net/connect/faq/
• Developers corner http://openid.net/developers/
  • OpenID Specification http://openid.net/developers/specs/
  • Core Spec http://openid.net/specs/openid-connect-core-1_0.html
  • Libraries http://openid.net/developers/libraries/
• Cerified OpenID Connect implementations
  • http://openid.net/certification/ 
  • http://openid.net/developers/certified/