OIDC federation - Amazon Identity and Access Management
Additional resources for OIDC federation
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

OIDC federation

Imagine that you are creating an application that accesses Amazon resources, such as GitHub Actions that uses workflows to access Amazon S3 and DynamoDB.

When you use these workflows, you make requests to Amazon services that must be signed with an Amazon access key. However, we strongly recommend that you do not store Amazon credentials long-term in applications outside Amazon. Instead, configure your applications to request temporary Amazon security credentials dynamically when needed using OIDC federation. The supplied temporary credentials map to an Amazon role that only has permissions needed to perform the tasks required by the application.

With OIDC federation, you don't need to create custom sign-in code or manage your own user identities. Instead, you can use OIDC in applications, such as GitHub Actions or any other OpenID Connect (OIDC)-compatible IdP, to authenticate with Amazon. They receive an authentication token, known as a JSON Web Token (JWT), and then exchange that token for temporary security credentials in Amazon that map to an IAM role with permissions to use specific resources in your Amazon Web Services account. Using an IdP helps you keep your Amazon Web Services account secure because you don't have to embed and distribute long-term security credentials with your application.

For most scenarios, we recommend that you use Amazon Cognito because it acts as an identity broker and does much of the federation work for you. For details, see the following section, Amazon Cognito for mobile apps.

Note

JSON Web Tokens (JWTs) issued by OpenID Connect (OIDC) identity providers contain an expiration time in the exp claim that specifies when the token expires. IAM provides a five-minute window beyond the expiration time specified in the JWT to account for clock skew, as allowed by the OpenID Connect (OIDC) Core 1.0 standard. This means OIDC JWTs received by IAM after the expiration time but within this five-minute window are accepted for further evaluation and processing.

Topics

Additional resources for OIDC federation

The following resources can help you learn more about OIDC federation: