OpenID Connect (OIDC) is a simple identity layer that sits on top of the OAuth 2.0 protocol. It enables clients to verify the identity of the end-user based on the authentication performed by an authentication server.
OIDC also obtains basic profile information about the end-user using REST API's and provides authentication as an added on functionality on top of OAuth which provides authorization. With OAuth, the user authenticates directly with the client application itself. OAuth provides a level of pseudo-authentication by providing a grant or license to access resources rather than providing information about the authentication itself.
OIDC can extend OAuth so cloud-based applications can get identity information, retrieve details about the authentication event, and allow federated single sign-on.
To understand how OIDC works in more detail please refer to How OIDC Works.
This quickstart guide serves as an integration example for our trusted partners so that you will be able to evaluate, test, and launch LoginID’s authentication service for your own needs. After going through this guide you should be able to have your application connect to our platform in less than 10 minutes (assuming you have your environment set up according to the requirement).
The End User is the entity for whom we are requesting identity information
The Relying Party is an OAuth 2.0 client that relies on the Identity Provider to authenticate
The Identity Provider is an OAuth 2.0 authorization server that ensures the End-User is authenticated and provides claims about the End-User and the authentication event to the Relying Party.
The Identity Provider provides the Relying Party information about the identity of the End User through an Identity Token. The identity token is similar to an ID card or passport. It contains a number of required attributes or claims about that end User but also how the End-User was authenticated such as:
Subject: a unique identifier assigned to a user by the Identity provider, for example
Issuing Authority: the Identity provider that issued the token
Audience: identifies the Relying Party who can use this token
Issue Date: date and time the token was issued
Expiration Date: Date and time the token was issued
Authentication time: shows the time the End-User was authenticated
Nonce: values that mitigate replay attacks
The Identity token is encoded as a JSON Web Token or JWT is are digitally signed using JSON signature to achieve integrity and non-repudiation.
OIDC uses claims to retrieve information but it can also use scopes such as profile, email, address, phone.
In the initial authentication request, the client application can request scopes or claims to be returned in the identity token. Alternatively, they can be requested using an access token through an RESP API call to the user info endpoints.
The OpenID Connect Identity Provider has a number of End Points with which the End-User and Client Application interact. These are the Authorization Endpoint, the Token Endpoint, and the UserInfo endpoint. The Authorization endpoint is where the End-User is asked to authenticate and grant the client application consent to access their identity, and any other required information such as email, or address. This extra information is called UserInfo claims.
Once consent is given, this endpoint passes back an Authorization code. This is the endpoint in which the End-User indirectly interacts with the Identity Provider through a user agent, for example, a browser. The token endpoint authenticates the client application. It also exchanges the authorization code from the Authorization endpoint, for an ID token, an access token, and an optional refresh token.
The UserInfo Endpoint is an OAuth 2.0 protected resource that is used by the Identity Provider to return consented user information or claims to the client application, provided that a valid access token is presented.
We’re happy to assist, if you have any questions please don’t hesitate to contact firstname.lastname@example.org.
Do you have any specific requests for example using other frameworks or programming languages? Contact us and let’s talk about bringing secure, private authentication into your application, we have engineers on standby to discuss.