In AWS, create one or more IAM roles. For each role, define who can assume the role (the trust policy or trust relationship) and what permissions the app's users will have (the access policy).
Create one role for each identity provider for each app. For example, you might create a role that can be assumed by an app where the user signed in using Login with Amazon, a second role for the same app where the user has signed in using Facebook, and a third role for the app where users sign in using Google. For the trust relationship, specify the identity provider (like Amazon.com) as the federated principal (the trusted entity), and include a condition that matches the app's ID. Examples of the roles for different providers are shown later in this topic.
In your application, authenticate your users using Login with Amazon, Facebook, Google, or an OIDC-compatible provider. To do this, call the identity provider using an interface that they provide. For example, you might call an API and pass the user's credentials and possibly other information that the provider requires. The exact way in which you authenticate the user depends on the provider and on what platform your app is running. Typically, if the user is not already signed in, the identity provider takes care of displaying a sign-in page for that provider. After the identity provider authenticates the user, the provider returns a token to your app.
In your app, make an unsigned call to the AssumeRoleWithWebIdentity action to request temporary security credentials. In the request, you pass the identity provider's token and specify the Amazon Resource Name (ARN) for the IAM role that you created for that identity provider. AWS verifies that the token is trusted and valid and if so, AWS STS returns temporary security credentials to your app that have the permissions derived from the role that you named in the request. The response also includes metadata about the user from the identity provider, such as the unique user ID that the identity provider assigned to the user.
Using the temporary security credentials you get in the AssumeRoleWithWebIdentity response, your app makes signed requests to AWS APIs. The user ID information from the identity provider can be used to distinguish users in the app—for example, you can put objects into Amazon S3 folders that include the user ID as prefixes. This allows you to create access control policies that lock that folder down so only the user with that ID can access it. For more information, see Identifying Providers, Apps, and Users with Web Identity Federation later in this topic.
Your app caches the temporary security credentials so that you do not have to get new ones each time the app needs to make a request to AWS. By default, the credentials are good for one hour. When the credentials expire (or before then), you make another call to AssumeRoleWithWebIdentity to obtain a new set of temporary security credentials. Depending on the identity provider and how they manage their tokens, you might have to refresh the provider's token before you make a new call to AssumeRoleWithWebIdentity, since the provider's tokens also usually expire after a fixed time. (If you're using the AWS SDK for iOS or the AWS SDK for Android, you can use the AmazonSTSCredentialsProvider action, which manages the AWS STS credentials, including refreshing them as required,,-**