A couple years ago if I wanted to automate the deployment of my project to AWS I needed to generate some keys and store them on GitHub. This would allow my GitHub build process to authenticate to AWS to upload my project. In present time you can do all of that without a single password, secret or key. This is the power of OIDC or OpenID Connect.

Just think about the past few years that we often had a vulnerability, exploit or compromised tool chain that results in some malware extracting every secret you have. This meant in those circumstances if those secrets were slightly misconfigured with too many permissions or not hardened you could have a worst case scenario on your hands.

Lets imagine you have an access key that expires every 90 days and is probably hardened to the specific permissions that key needs. Maybe that’s uploading a file and triggering a new deploy or something like that, but that is still a possible vector if it leaks. If you had a key that was ephemeral for the state of the action and auto-generated at the time it was needed that is basically what OIDC is under the hood.

Creating an Identity Provider on AWS

If I was setting this up I’d first need to teach AWS the provider I’m attempting to communicate with. In this case GitHub and AWS offer a guide to get this configured the right way. The important thing is how each service authenticates with the other and how they determine the other side is authenticated to mint a token.

Lets explain this a different way.

• GitHub wants to securely talk to Amazon for your specific thing.

• GitHub creates a short-lived JWT token signed by themselves.

• That JWT has a ton of claims (fields) that are immutable and specific to that execution

• Think repository, branch, workflow, sha, ref, etc

• Amazon gets that JWT and can validate it its authenticity against GitHub’s published key.

• You (on AWS) then tell AWS how they should validate any GitHub verified JWT against your project.

• Think specific workflow on a specific branch or tag.

• If Amazon validates the JWT against everything it checked it returns temporary credentials to GitHub for Amazon

• Think an AWS Access/Secret key only good for a period of time.

When you think about this its such an interesting dynamic. It works when two companies agree on a standard an implement it securely. Amazon trusts GitHub to create secure temporary JWT that they can verify.

Amazon depends on the end user to harden the ODIC integration specific to their need. Imagine this sample configuration file.

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
},
"StringLike": {
"token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main"
}
}
}
]
}

Example policy on AWS for GitHub OIDC

This means when a request is issued AWS wants to use this policy to check information on the GitHub JWT to ensure its complaint for your usage. This prevents a random GitHub project being validated to talk to your AWS account.

From a compliance perspective this is just amazing. When an auditor asks if you rotate secrets every x days - the benefit of this flow is you have no secrets to rotate. So I started looking into every avenue of services I use in work/hobby to see if they supported it.

• NPM (NodeJS) has Trusted Publishing
• Packagist (PHP) has Trusted Publishing
• RubyGems (Ruby) has Trusted Publishing
• GitHub of course has OIDC support
• Google has Workload Identity Federation through a Service Account

I was sad to discover a few services that did not support OIDC.

• Apple still only has the App Store Connect API which works via a secret.
• DockerHub still forces a Personal Access Token (PAT) flow for uploads, but an outstanding issue of 3 years is requesting this enhancement.

I’m happy to continue removing long term secrets for ephemeral tokens powered via OIDC. I just hope the industry continues putting pressure on the companies and services that still do this day require a more archaic method of authentication.