Federated Identity is a means through which a service or application does not need to obtain and store users’ credentials to authenticate users. Instead it can use another service or application, which acts as a repository of users’ identities, to authenticate the user. This has two main benefits:
- Users do not need to remember a lot of credentials as there are only a few sites where they have their identity stored which can be used to sign into other sites.
- These selected sites have identity management as one of their core competencies which means they provide a higher level of security and protection to the data they store.
Open ID Connect is a simple JSON\ REST- based interoperable identity protocol built on top of OAuth2.0. Its design philosophy is ‘make simple things simple and complicated things possible’.
It provides flexible user authentication by allowing identity providers to choose their preferred way of authentication such as username/password, hardware tokens, biometrics, etc. It provides built-in user provisioning by defining a UserInfo HTTPS endpoint for authorized client applications to retrieve consented information about the logged in user. The Open ID Connect server provides client applications with two key tokens-
ID token: It can be compared with an identity card in a digital format. A typical ID token contains a JSON object with the following details:
- User identifier
- Issuing authority
- Client application
- Time of issue and expiry
- How and when was authentication done
- Access token: It can be compared with a physical token or a ticket. It permits user access to a specific HTTP resource or web service. Open ID Connect employs OAuth2.0 access tokens.
OpenID Connect is designed for the consumer-to-social-network scenario, but can potentially be deployed in different use cases such as identity federation or federation single sign on. Some big vendors (Google, Microsoft) support OpenID Foundation in their development effort. OpenID Connect achieves the same goals that SAML 2.0 is currently used for but It has certain features such as asking for user consent, can deal with higher levels of assurance and supports IdP discovery, dynamic client registration, and session management though these are optional features.
You may like to read the attached document, which explains in detail about following:
- OpenID Connect Specification
- OpenID Connect Architecture
- OpenID Connect Use cases
- Comparison between OpenID Connect, OAuth2.0 and SAML 2.0
- Future scope of OpenID Connect
Authored by Sachin Saroch