Definition of OAuth 2.0 and OIDC 1.0

OAuth 2.0

OAuth 2.0 is a protocol that allows third-party applications to access user data without requiring the user's password. With OAuth 2.0, applications obtain an Access Token that grants permission to access user data stored on other servers (e.g., data in social media accounts or cloud services).

This protocol simplifies integration between various applications, such as web, mobile, and server-to-server applications. OAuth 2.0 ensures that only authorized apps can access specific data, and only for a limited duration. Additionally, if an access token expires, a Refresh Token allows applications to obtain a new token without requiring the user to re-login.

Main Components of OAuth 2.0

1. Client
   An application that requests access to user data or resources. This client is usually a third-party application, such as a web or mobile application.

2. Resource Server
   The server that stores the user data the application wants to access. It serves data requests made using the Access Token.

3. Resource Owner
   The user who owns the data stored on the resource server. This user gives permission to applications to access their data.

4. Authorization Server
   A server that issues access tokens after verifying the permission of the resource owner. The Authorization Server is also in charge of managing the authorization flow and issuing Access Tokens and Refresh Tokens when necessary.

OpenID Connect (OIDC) 1.0

OIDC (OpenID Connect) 1.0 a protocol that builds on OAuth 2.0 to add authentication features. Simply put, OIDC allows applications to verify a user's identity using an ID Token issued by an OpenID Provider (INApas).

With OIDC, users only need to login once Single Sign-On to access various applications, without having to re-login in each application. OIDC provides an ID Token that contains information about the user (such as name and email), which the app uses to ensure that they are an authorized user. All this information is protected with a digital signature to ensure the authenticity of the data.

Key Components of OpenID Connect

1. OpenID Provider (OP)
   The OpenID Provider is the service that authenticates users and issues ID Tokens. In this case, INApas acts as the OpenID Provider, publishing ID Tokens after successful user authentication. OIDC introduces the concept of an ID Token, which contains claims (user-related data) such as user identity and authentication information.

2. End-User (Final User)
   The end-user is the person whose authentication process is managed by the OpenID Provider. Information about the user's authentication is included in the ID Token.

3. Relying Party (RP)
   A Relying Party is the client application that relies on the OpenID Provider for user authentication. These applications use the ID Token to verify the user's identity.

4. ID Token
   An ID Token is a token produced by the OpenID Provider that contains claims about the user, such as their name, email, and other relevant information. This token is used by applications to verify that the logged-in user is legitimate.

Aspect	OAuth 2.0	OIDC 1.0
Main Focus	Authorization (access to user data)	Authentication (verifying user identity)
Token Issued	Access Token, Refresh Token	ID Token, Access Token, and Refresh Token
Purpose	Give permission to the app to access user data	Verify user identity and provide user information
Information Provided	Access to user resources (without user identity information)	User authentication information (such as name and email)
Usage	Accessing data from resource servers	Providing Single Sign-On (SSO) and user authentication for applications

With this table, the differences between OAuth 2.0 and OpenID Connect 1.0 become clearer, especially in terms of the focus of authorization and authentication and the type of token issued.

INApas Authorization and Authentication Flow (OAuth 2.0 & OpenID Connect 1.0)

1. User Clicks Login Button

The user initiates the login process by clicking the Login button within the RP application, whether it’s a web or mobile application. This triggers the authorization request to INApas (Authorization Server).

2. RP Application Sends Authorization Request to INApas

The RP Application then sends an Authorization Request to INApas (the Authorization Server) to request access to the user's data. This request includes key parameters like:

• client_id: The application's unique identifier.
• redirect_uri: The URI where INApas will send the user after authentication.
• scope: Specifies the permissions the app is requesting (e.g., access to user profile data).
• response_type=code: Indicates that the app is requesting an authorization code.

INApas provides the authorization code

After users have successfully logged in and given agreement to give access to the RP application, INApas provides an authorization code in response to the RP application. OAuth 2.0 uses authorization codes as the first stage in the Authorization Code Flow, which provides a higher level of security as it does not send access tokens directly.

4. RP Application Exchanges Authorization Code for Token

The application uses the authorization code to request an Access Token and Token ID to INApas. This request contains:

• client_id: Identifies the application that requested the token.
• client_secret: Verifies the identity of the application (if required).
• code: Authorization code received from INApas.
• redirect_uri: Must match the URL used in the initial authorization request.

5. INApas Returns Token:

If the authorization code is valid, INApas provides:

• Access Token: To access user data as authorized.

• (Optional) Refresh Token: To extend the access period.

• (Optional) ID Token: If the app requests an openid scope, INApas will also return an ID Token to verify the user's identity. This ID token allows the app to ensure the logged in user is an authorized user. OAuth 2.0 allows applications to access data without needing to know the user's credentials

6. Token ID Verification:

The RP application verifies the received Token ID using JWT digital signature to ensure that the token is issued by INApas (OpenID Provider). OIDC allows the RP application to verify the identity of the user and ensure the authenticity of the user's data before granting access to the application.

Key Security Standards

• Proof Key for Code Exchange (PKCE): Improves security by preventing authorization code interception attacks. We use SHA-256 based HMAC for PKCE verification.

• JSON Web Token (JWT) Assertions: Provides a secure method to verify client identity. We use Elliptic Curves P-512 algorithm which is fast and secure.

Cryptographic Details

1. Signing:

   • Algorithm: ES512 (Elliptic Curve Digital Signature Algorithm with SHA-512)

2. Encryption:

   • Key Exchange: ECDH-ES (Elliptic Curve Diffie-Hellman with Ephemeral Static key)
   • Key Wrapping: A256KW (AES Key Wrap with 256-bit key)

Explanation of the Type of Token Used

Token Type	Description
Access Token	A token issued by the authorization server after the user grants permission to access their data. It is used to make requests to the resource server while authenticating the application.
Refresh Token	A token issued alongside the Access Token, used to obtain a new Access Token when the old one expires, without requiring the user to log in again.
ID Token	A token containing authentication information about the user, such as name, email, and claims related to other users, used by the application to verify the user's identity.

Resources and Support

• OpenID Connect Specification
• OAuth 2.0 Specification