What is OpenID Connect (OIDC)?
OpenID Connect is a simple authentication protocol, built on top of the OAuth2 protocol as a separate identity layer. OAuth2 is an authorization protocol, which is being extended by the OIDC, to implement its authentication mechanism. OIDC allows the applications to authenticate and verify the end-users based on the authentication performed by an Authorization Server, which supports OIDC. This also allows the application to obtain basic profile information, about the end-user in an interoperable and REST-like manner. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”.
(Identity, Authentication) + (OAuth 2.0) = (OpenID Connect)
The OpenID Connect protocol is very flexible in which it gives the power to the client, to easily customize the authentication process according to their needs. OIDC gives the power to clients of all types, including Web-Based, mobile, and JavaScript clients, to request and receive information regarding the authenticated sessions and end-users. The main extensible features provided by the OIDC protocol are,
- Encryption of Identity Data
- Discovery of OpenID Providers
- Session Management
This blog provides an abstract idea of what OpenID Connect is and, its important specifications.
History of OpenID Connect
OpenID Connect is the third generation of OpenID Technology. The original OpenID authentication protocol was developed by Brad Fitzpatick in May 2005. This was more like a visionary tool which never got much commercial adoption, but it got people to think of its possibilities and extensions. In the meantime, OpenID and OAuth were focused on two different aspects of an internet identity, whilst OpenID played the role of authentication, whereas the OAuth played the role of authorization. Since these two extensions were playing a huge role in each of its domains, the need to combine both these protocols arose.
As the second generation of OpenID, it came as an extension for OAuth, which was named as OpenID 2.0. This was better than the earlier version, and it provided much more security and worked seamlessly when implemented properly. Even though it had some design limitations, the implementation of OpenID 2.0 was fully thought through. The third generation of OpenID is the “OpenID Connect.” Unlike OpenID 2.0, this was built on top of OAuth 2.0 as a separate identity layer. The “OpenID Connect’s goal is to be much more developer-friendly and providing a wide range of use cases where it can be implemented. Currently, this has been very successful and deployments are happening on huge scales.
OpenID Connect vs OpenID 2.0
The functionalities available in the OIDC and OpenID 2.0 are pretty much the same whereas the OIDC provides much more API-friendly and usable implementations for native mobile applications. “OpenID Connect” defines optional capabilities for robust signing and encryption. To integrate OpenID 2.0 and OAuth 1.0, we require an extension, whereas in OIDC, OAuth 2.0 protocols, OAuth 2.0 functionalities are integrated within the protocols itself.
OpenID 2.0 used XML and custom message signature schemes that in practice, sometimes proved to be difficult for developers to implement. But in OAuth 2.0, the OIDC outsources the necessary encryption to the web’s built-in TLS (also called HTTPS or SSL) infrastructure, which is universally implemented on both client and server platforms. OIDC uses standard JSON Web Tokens (JWT) when signatures are required. Since JWT is more familiarized and easier to use, this makes OIDC dramatically easier for developers to implement, and practically has resulted in much better inter-operability.
About the OpenID Foundation (OIDF)
The OpenID Foundation was formed in June 2007, and it is an international non-profit organization of individuals and companies committed to enabling, promoting, and protecting OpenID technologies. The OIDF serves as a public trust organization representing the open community of developers, vendors, and users.
This foundation provides a much-needed infrastructure to the community and helps in promoting and expanding OpenID technologies. This entails managing intellectual property and brand marks as well as fostering viral growth and global participation in the proliferation of OpenID.
What Companies & People involved in the development of OIDC?
Contributors include a diverse international representation of the industry, academia and independent technology leaders: AOL, Deutsche Telekom, Facebook, Google, Microsoft, Mitre Corporation, mixi, Nomura Research Institute, Orange, PayPal, Ping Identity, Salesforce, Yahoo! Japan, among other individuals and organizations.
Mobile Network Operators and OpenID Connect
In the modern digital era, we can see a considerable increase in the number of users using online services via mobile devices, and due to this reason, there is an increase in identity thefts all around the world. The GSMA created a valuable business proposal for Mobile Network Operators so that they can join hands with OIDC to implement and render many services to its customers. This business model states that Mobile Network Operators, short for MNOs, with their differentiated identity and authentication assets, have the ability to provide sufficient authentication to enable consumers, businesses, and governments to interact in a private, trusted, and secure environment and enable access to services.
MNOs increasingly are interested in identity services currently being used online (i.e. login, marketing, post-sales engagement, payments, etc.), to mitigate some of the pain points encountered in existing services, in order to meet the rapidly increasing market demand for mobile identity services.
OpenID Specifications
OpenID Connect Flow
OpenID Connect follows the following sequence of steps.
- RP — Relying Party
- OP — OpenID Provider
- The RP (Client) sends a request to the OpenID Provider (OP)
- The OP authenticates the End-User and obtains authorization
- The OP responds with an ID Token and usually an Access Token
- The RP can send a request with the Access Token to the UserInfo Endpoint
- The UserInfo Endpoint returns Claims about the End-User
The flow of events in OIDC
- The client prepares an Authentication Request containing the desired request parameters.
- The client sends the request to the Authorization Server.
- Authorization Server authenticates the End-User.
- Authorization Server obtains End-User Consent/Authorization.
- Authorization Server sends the End-User back to the Client with code.
- The client sends the code to the Token Endpoint to receive an Access Token and ID Token in the response.
- The client validates the tokens and retrieves the End-User’s Subject Identifier.
Contacting the Authorization Endpoint
Mandatory Parameters:
- response_type: Asking for the response required
- client_id : OAuth 2.0 Client Identifier valid at the Authorization Server
- scope: Specify what access privileges are being requested for Access Tokens
- redirect_uri : Redirection URI to which the response will be sent
- state : Value used to maintain state between the request and the callback
Optional Parameters:
- nonce: Value used to associate a Client session with an ID Token, and to mitigate replay attacks
- display: Value that specifies how the Authorization Server displays the authentication and consent user interface pages to the End-User
- prompt: Values that specifies whether the Authorization Server prompts the End-User for reauthentication and consent
- max_age: Maximum Authentication Age
- ui_locales: End-User’s preferred languages and scripts for the user interface
- claims_locales: End-User’s preferred languages and scripts for Claims being returned
- id_token_hint: ID Token previously issued by the Authorization Server
- login_hint: Hint to the Authorization Server about the login identifier
- acr_values: Requested Authentication Context Class Reference values
End-user Grants Authorization
If the End-User grants the access request, the Authorization Server issues a code and delivers it to the Client by adding the following query parameters to the query component of the redirection URI.
Mandatory Parameters
- code: Authorization Code
- state: OAuth 2.0 state value
Contact the Token Endpoint:
A Client makes a Token Request by presenting its Authorization Grant (in the form of an Authorization Code) to the Token Endpoint
Mandatory Parameters:
- grant_type : The type of “code” that is being submitted
- code: Value you received from the Authentication request’s response
- redirect_uri: Used as an extra level of security.
Client Receives Token
Mandatory Parameters
- access_token: Access Token for the UserInfo Endpoint
- token_type: OAuth 2.0 Token Type value
- id_token: ID Token
Optional Parameters
- expires_in: Expiration time of the Access Token in seconds since the response was generated
- refresh_token: Refresh Token
Contact User Info Endpoint
Clients send requests to the UserInfo Endpoint to obtain Claims about the End-User using an Access Token obtained through OpenID Connect Authentication. The request SHOULD use the HTTP GET method and the Access Token SHOULD be sent using the Authorization header field.
