Five OpenID Connect sign-ins, from a person signing in with Google to a GitHub Actions job, a pod on EKS and a GitLab job reaching AWS and Vault without stored keys, each sorted into the same three roles — the provider that signs the token, the user it is about, and the app that trusts it.
The three roles
In every OpenID Connect sign-in, a user wants to log in to an app, and the app lets a third party, the provider,
say who the user is. The same three roles, whoever plays them:
- OpenID Provider:
The party holding the identities and signing the token.- It publishes its public keys at a fixed address, so anyone can check its signature.
- User:
The party the token is about.- A person in a browser, or a program: a CI job or a pod.
- App (relying party):
The party the user signs in to.- It trusts the provider's signature, and decides by itself what the user may do.
The token's three claims
The token names the three corners:
iss, the issuer: the provider.sub, the subject: the user.aud, the audience: the app.- An app refuses a token whose
aud is not its own, so a token made for one app cannot be used at another.
The stories
| Story | Provider | User | App |
|---|
| A person signs in with Google | Google | dana, in her browser | cook.example |
| A GitHub Actions job deploys to AWS | GitHub's OIDC provider | the deploy job | AWS STS |
| kubectl signs in to a Kubernetes cluster | Keycloak | the developer, with kubectl | the API server |
| A pod on EKS writes to S3 (IRSA) | the EKS cluster | the pod | AWS STS |
| A GitLab CI job reads a secret from Vault | GitLab | the CI job | HashiCorp Vault |
Web Security, Part 7: OpenID Connect runs the first kind of story message by message: a
person, a provider and an app, and the checks the app runs on the ID token.