Cloud security : OpenID Connect (OIDC) for digital identity challenges

In this article, we'll explore OpenID Connect (OIDC) and how it has emerged as an essential solution to address the challenges of digital identity management and cybersecurity. Join us as we simplify OIDC, exploring how it works, its benefits, and our feedback following its successful implementation with our clients, aiming to mitigate the risks associated with long-term credential sharing and the potential leakage of such sensitive information.
‍

I. What is OIDC?

OpenID Connect (OIDC) is an authentication protocol built upon the OAuth 2.0 standard.

While OAuth focuses on authorisation, OIDC introduces an additional layer of security by enabling authentication. It allows clients[1] to authenticate users and receive confirmation of their identity through an ID Token.

Recognised for its user-centric approach and ease of integration into existing authentication systems, OIDC marks a significant evolution in digital identity management, providing a more secure and standardised mechanism.

Key components include:

1. ID Token: A JSON-formatted security token containing the user's identity and signed by the authentication server.
2. UserInfo Endpoint: A service for obtaining user information after successful authentication.
3. Discovery Document: A JSON document with the necessary metadata for client-server interactions.
4. Dynamic Client Registration: A process allowing a client to register with an OIDC server.
   ‍

II. General Operation

‍Types of “Grants”

OIDC enables a client, such as a web or mobile application, to verify the user's identity and obtain basic profile information via a trusted authentication server. It uses various grant types to facilitate different authorisation flows.

A "grant" in this context refers to a method or mechanism through which an application gains authorisation to access certain resources or data. Each grant type offers a different approach to obtaining this authorisation, depending on the application's context and security requirements.

The primary grant types are:

• Authorisation Code Grant: This is the most common flow, especially for applications that can securely store a client secret. It involves an authorisation server issuing an authorisation code, which the client then exchanges for an ID token and an access token.
• Implicit Grant: Designed for applications where the client cannot securely store a client secret, such as single-page applications (SPAs). This flow returns an ID token and/or an access token directly after the user authenticates, without an intermediate authorisation code.
• Client Credentials Grant: Used for server-to-server communication where the client acts on its own behalf, not on behalf of a user. It's typically used for backend services or daemons.
• Device Code Grant: Applicable to devices without an easy means of text entry, such as smart TVs or IoT devices. This flow involves a device displaying a code for the user to enter into another device with better input capabilities.
• Refresh Token Grant: Allows a client to obtain new access tokens without re-authenticating, using a refresh token issued alongside the access and ID tokens.

These grant types enable various user authentication and authorisation scenarios, catering to a variety of application types and security requirements.

‍

Tokens

OIDC uses tokens to facilitate authentication and authorisation in web applications and services. The main tokens are the ID Token and the Access Token:

• ID Token: A JWT (JSON Web Token) containing the user's identity information, digitally signed by the authentication server.
• Access Token: Used to access protected resources on the resource server, such as APIs.

Here's an example of an OIDC token in JSON format:

This token includes standard fields such as the issuer (iss), subject (sub), audience (aud), expiration time (exp), and issuance time (iat), as well as user-specific information like name and email address.

Discovery

OIDC (OpenID Connect) provides a discovery mechanism, an essential feature to facilitate automatic interaction between clients (such as web or mobile applications) and the authentication server.

Here are some key points about this discovery mechanism in OIDC:

1. Discovery Endpoint: Allows the automatic retrieval of the OIDC server's configuration via a standardised endpoint.
2. Metadata Retrieval: Obtains the OIDC server's URLs and configurations automatically to simplify client integration.
3. Public Keys: Provides server public keys for secure verification of token signatures.

Security and token validation

Security in OIDC is ensured through rigorous token validation mechanisms. Clients [1] must not only verify the tokens' signature but also ensure that the token is intended for their use (by checking the token's aud field), that the user is the one indicated in the token (by verifying the token's sub field), and that the token has not expired (exp fields).

Example: OIDC authentication flow between GitHub Actions and AWS

In the context of integration between GitHub Actions and AWS via OIDC, the "Client Credentials Grant" is a mechanism through which GitHub Actions authenticate with AWS as a client. This allows GitHub Actions to obtain temporary AWS credentials to access necessary resources without the need to permanently store AWS access keys (long-term) in GitHub configurations.

1. GitHub Pipeline Trigger: When a GitHub pipeline is triggered, GitHub retrieves the credentials using the aws-actions/configure-aws-credentials. This action requires the role-to-assume parameter. It implements the AWS SDK credential resolution chain.

2. Requesting Credentials from AWS IAM: The request for credentials reaches AWS IAM's identity provider. This provider trusts GitHub via certificates, establishing a federated relationship between GitHub and AWS [source].
   ‍
3. Authorization and Assignment of Temporary Credentials: If permitted, GitHub receives temporary access keys and an ID in return, allowing it to assume the role specified in role-to-assume. GitHub Actions can access necessary AWS resources based on permissions defined within the IAM role [source].
   ‍

‍

III. Advantages
‍

1. Passwordless Authentication

The integration of OIDC represents a shift towards passwordless authentication, prioritising enhanced security and a better user experience. Passwords, often susceptible to compromise, are replaced by authentication tokens and identity assertions that OIDC uses for a safer and more transparent user experience.
‍

2. Security

The impact on IT system security is significant:

1. Centralisation of Identity Management: OIDC centralises identity management, reducing complexity and risks associated with managing multiple authentication systems.
2. Authentication Delegation: By delegating authentication to trusted service providers, organisations limit the risks of internal security breaches.
3. Limited Lifespan Tokens: The use of temporary tokens decreases the risk of compromise of long-term credentials because even if a token is intercepted, it will only be valid for a short period.
   ‍

3. Compliance with Regulations

The adoption of OpenID Connect (OIDC) helps businesses comply with data protection regulations, such as GDPR, in two main ways:

1. Reduced Identity Data Management: OIDC reduces the need to store and manage sensitive identity data, aligning practices with GDPR's data minimisation principles.
2. Enhanced Data Security: By using secure tokens and robust authentication, OIDC strengthens the protection of personal data, a key aspect of GDPR compliance.
   ‍

4. Centralised Identity Management

The adoption of OpenID Connect (OIDC) offers a centralised approach to identity management within enterprises. This simplifies user management by reducing the inherent complexity of managing multiple authentication systems. Additionally, by delegating authentication to trusted service providers, organisations minimise the risks of internal security breaches.
‍

5. Integration

In addition to the previously mentioned benefits of OIDC integration, here are further advantageous points to consider:

• Enhanced Interoperability: Facilitates integration with diverse systems and technologies through open standards, improving cross-platform compatibility.
• Support for Modern Authentication Flows: Supports advanced authentication methods like mobile and biometric authentication.
• Simplified Security Updates: Centralises security policy updates and certificates, reducing maintenance efforts.
• Role-Based Access and Permissions (Policy): Facilitates the implementation of sophisticated access controls for fine-grained permission management.
• Improved Traceability and Audit: Enhances authentication traceability and streamlines audits, essential for compliance and risk management.
• Reduced Attack Surface: Minimises entry points for potential attacks, enhancing the overall security of the organisation.

In summary, OIDC contributes to a more robust, secure, and easily manageable security architecture within modern computer systems.

‍

IV. Experience Feedback

The integration of AWS and GitHub via OIDC is a common use case aimed at automating and securing the deployment of applications in the AWS cloud from GitHub Actions' CI/CD pipelines.

Setup
‍

    1. OIDC Configuration on AWS:

• Creation of an OIDC identity provider in AWS IAM linked to GitHub.
• Configuration of IAM roles with policies allowing access to necessary AWS resources.

   2. GitHub Actions Configuration:

• Establishment of GitHub Actions workflows for integration with AWS.
• Use of OIDC authentication to acquire temporary AWS credentials.

The initial setup of the integration between AWS and GitHub is relatively straightforward. However, the most critical and complex part involves the proper configuration of IAM roles. It is vital to precisely define the condition token.actions.githubusercontent.com:sub to specifically limit the GitHub organizations, repositories, or branches that can assume this role. This configuration is essential to ensure adequate security.

Regarding the configuration of GitHub Actions, setting up permissions is straightforward:
‍

Source : Configuring OpenID Connect in Amazon Web Services - GitHub Docs

‍

V. Conclusion

OIDC is a strategic choice for companies aiming to strengthen the security of their IT infrastructures. It's a comprehensive solution that integrates both authentication and authorisation, thereby facilitating the development of secure applications compliant with regulations such as GDPR.

The key advantages of OIDC include:

• Centralised identity management,
• Passwordless authentication,
• Enhanced security,
• Easy integration with systems like GitHub Actions or Terraform Cloud for secure deployments in the AWS cloud,
• Simplified user experience.

Glossary

[1] An OIDC (OpenID Connect) client is an application or service that interacts with an Identity Provider (IDP) using the OIDC protocol to authenticate users.

[2] An Identity Provider (IDP) is a system or service that authenticates users and provides credential information to applications and services.