OpenID Connect (OIDC) is a modern authentication and authorization protocol built on top of the 0Auth 2.0 framework. OIDC enables secure and standardized authentication in applications, particularly web and mobile applications.
But while OIDC improves security, minimizing user credential exposure, it can introduce security risks such as misconfigured identity and access management (IAM) policies. With a proactive approach to security, however, you can ensure that your configurations are secure, freeing your organization to reap the benefits of OpenID Connect.
Introduction to OIDC
OpenID Connect enables users to authenticate and authorize themselves to access APIs, protected data and other resources on different websites or services. The key differentiator of OIDC is that users don’t need to share credentials, like passwords, directly with those services.
Instead, OIDC enables the use of tokens — such as ID tokens and access tokens — to establish the user’s identity and grant limited and controlled access to the user’s data.
OIDC provides several benefits, including:
- Single sign-on (SSO) across different applications and services
- A standardized way to manage user identities and access control
- Reduced exposure of user credentials
Why Should I Use OpenID Connect?
Storing credentials in applications poses risks. When bad actors compromise an application, perhaps via a GitHub Actions workflow, they can potentially expose all passwords stored in the application.
Because OIDC uses tokens rather than passwords for authentication, it provides several security benefits over traditional authentication methods. Access tokens have expiration times, and you can revoke and enforce their scope. With granular control over access tokens, you can reduce the potential impact of a data breach.
In addition to security benefits, OIDC provides a better user experience than storing credentials in applications.
With Great OIDC Comes Great Responsibility
Despite the security benefits of OpenID Connect, using this protocol can introduce misconfigurations and expose you to new attack vectors. Let’s dive into how misconfigured policies can make their way into your GitHub environment.
Like most developer-centric tools, the GitHub Actions platform prioritizes usability, which often sidelines security. But cloud-native organizations must consider CI/CD security as critically important and proactively address common CI/CD attack vectors. The recent CISA and NSA guidance, in addition to the OWASP Top 10 CI/CD Security Risks project, provide evidence that we need to implement tighter controls.
Now that GitHub supports OIDC within GitHub Actions workflows, GitHub Actions can retrieve short-lived session tokens on demand rather than using credentials stored locally.
At a high level, when using OIDC, a request is made to an OIDC supporting cloud provider to exchange a JWT ID token for a short-term session token. As part of your cloud setup, you need to create a cloud identity provider with a URL and a client ID to ensure that your request originates from an allowed client.
Tinder Labs’ research demonstrates that after completing the creation of an identity provider, you can assign IAM roles to it and establish a trust relationship between GitHub and the cloud.
This trust relationship validates two specific keys: aud and sub.
- aud: The aud value is the audience string specified in the workflow. For example, the default aud value is sts.amazonaws.com for the configure-aws-credentials GitHub action.
- sub: The sub is the subject payload in the request sent by GitHub. For example, the repository namespace and the branch repo:org_name/repo_name:ref:branch_ref.
Without the sub component, any external repository can assume the cloud provider role and access resources. If you do a quick search on GitHub, you’ll discover workflows using the configure-aws-credentials action in tandem with the misconfigured trust relationship. A missing sub component of the policy presents a significant issue.
Another issue involves the use of well intended but poorly executed wildcards within the sub key — e.g., repo:PaloAltoNetworks*/repo*. Wildcards enable the creation of a new organization on GitHub called PaloAltoNetworksFake and a new repoFake of any name that complies with the regex filter.
Getting Started with OIDC Security
Now that you know about common security issues associated with OIDC, how do you protect your organization from this attack vector? The most effective strategy to stay ahead of these misconfigurations is to proactively identify them in your IAM policies with a code scanning solution.
Checkov, our open-source infrastructure-as-code scanning tool, provides the misconfiguration scanning you’ll need to identify and address OIDC issues like the missing sub components and misconfigured trust relationships outlined above.
Shifting Your OIDC Security Left
OIDC provides a secure, standardized and user-centric approach to authentication that reduces the potential impact of a data breach. Despite the security benefits of OIDC, you need to keep in mind that creating IAM trust relationship policies associated with cloud identity can introduce security issues. But when you introduce tools like Checkov into your IDE and CI/CD pipeline, your teams can catch misconfigurations early and help secure your environment from attack.
If you’d like to learn more best practices to help safeguard your CI/CD pipelines — including practical tips to build a reliable IAM strategy — download the CI/CD Security Checklist.