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 inter-operable 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,
1) Encryption of Identity Data
2) Discovery of OpenID Providers
3) Session Management
This blog provides an abstract idea on 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's tool which never got much commercial adoption, but it got people to think of its possibilities and extensions. In the mean time OpenID and OAuth were focused on two different aspects of 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. Eventhough 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 the 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 implemented. Currently this has been very successful and deployments are happening in 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 a 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 scheme 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 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 included a diverse international representation of 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 MNO's, with their differentiated identity and authentication assets, have the ability to provide sufficient authentication to enable consumers, businesses, and governments to interact in 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 in abstract, follows the following sequence of steps.
RP - Relying Party
OP - OpenID Provider
(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
The Code Flow of OIDC
Client prepares an Authentication Request containing the desired request parameters.
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.
Client sends the code to the Token Endpoint to receive an Access Token and ID Token in the response.
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.
References:
#OIDC #openidconnect #openid #connect #WhatisOIDC #OpenIdConnect #HistoryofOpenIDConnect #OpenIDConnectvsOpenID20 #AbouttheOpenIDFoundationOIDF #OIDF #OpenIDFoundation #MNO #MobileNetworkOperator #OpenIDSpecs #OpenIDSpecifications #OpenIdConnectFlow #Authorizationendpoint #TokenEndpoint #UserInfoEndpoint