# Customer managed applications
IAM Identity Center acts as a central identity service to your workforce users and groups. If you already use an identity provider (IdP), IAM Identity Center can integrate with your IdP so that you can provision your users and groups into IAM Identity Center and use your IdP for authentication. With a single connection, IAM Identity Center represents your IdP in front of multiple AWS services and enables your OAuth 2.0 applications to request access to data in these services on behalf of your users. You can also use IAM Identity Center to assign your users access to [SAML 2.0](https://wiki.oasis-open.org/security) applications. This includes AWS services such as Amazon Connect and AWS Client VPN, which integrate with IAM Identity Center exclusively using SAML and are therefore categorized as customer managed applications.
+ If your application supports **JSON Web Tokens (JWTs)**, you can use the trusted identity propagation feature of IAM Identity Center to enable your application to request access to data in AWS services on behalf of your users. Trusted identity propagation is built on the OAuth 2.0 Authorization Framework and includes an option for applications to exchange identity tokens that come from an external OAuth 2.0 authorization server for tokens issued by IAM Identity Center and recognized by AWS services. For more information, see [Trusted identity propagation use cases](trustedidentitypropagation-integrations.md).
+ If your application supports **SAML 2.0**, you can connect it to an [organization instance of IAM Identity Center](identity-center-instances.md). You can use IAM Identity Center to assign access to your SAML 2.0 application.
**Note**
When integrating customer managed applications with an IAM Identity Center instance that uses a [customer managed KMS key](encryption-at-rest.md), verify whether the application invokes IAM Identity Center service APIs to confirm whether the application needs KMS key permissions. Follow the guidance for granting KMS key permissions to custom workflows in the IAM Identity Center User Guide's [ baseline KMS key policies](baseline-KMS-key-policy.md#baseline-kms-key-policy-statements-for-use-of-custom-workflows-with-iam-identity-center).
**Topics**
+ [Single sign-on access to SAML 2.0 and OAuth 2.0 applications](customermanagedapps-saml2-oauth2.md)
+ [Setting up customer managed SAML 2.0 applications](customermanagedapps-saml2-setup.md)
# Single sign-on access to SAML 2.0 and OAuth 2.0 applications
IAM Identity Center enables you to provide your users with single sign-on access to SAML 2.0 or OAuth 2.0 applications. The following topics provide a high-level overview of SAML 2.0 and OAuth 2.0.
**Topics**
+ [SAML 2.0](#samlfederationconcept)
+ [OAuth 2.0](#oidc-concept)
## SAML 2.0
SAML 2.0 is an industry standard used for securely exchanging SAML assertions that pass information about a user between a SAML authority (called an identity provider or IdP), and a SAML 2.0 consumer (called a service provider or SP). IAM Identity Center uses this information to provide federated single sign-on access for those users who are authorized to use applications within the AWS access portal.
**Note**
IAM Identity Center does not support validating signatures of incoming SAML authentication requests from SAML applications.
## OAuth 2.0
OAuth 2.0 is a protocol that allows applications to access and share user data securely without sharing passwords. This capability provides a secure and standardized way for users to allow applications access to their resources. Access is facilitated by different OAuth 2.0 grant flows.
IAM Identity Center enables applications that run on public clients to retrieve temporary credentials to access AWS accounts and services programmatically on behalf of their users. Public clients are typically desktops, laptops, or other mobile devices that are used to run applications locally. Examples of AWS applications that run on public clients include the AWS Command Line Interface (AWS CLI), AWS Toolkit, and AWS Software Development Kits (SDKs). To enable these applications to obtain credentials, IAM Identity Center supports portions of the following OAuth 2.0 flows:
+ Authorization Code Grant with Proof Key for Code Exchange (PKCE) ([RFC 6749](https://www.rfc-editor.org/rfc/rfc6749#section-4.1) and [RFC 7636](https://www.rfc-editor.org/rfc/rfc7636))
+ Device Authorization Grant ([RFC 8628](https://datatracker.ietf.org/doc/html/rfc8628))
**Note**
These grant types can be used only with AWS services that support this capability. These services may not support this grant type in all AWS Regions. Refer to the documentation of relevant AWS services for regional differences.
OpenID Connect (OIDC) is an authentication protocol that is based on the OAuth 2.0 Framework. OIDC specifies how to use OAuth 2.0 for authentication. Through the [IAM Identity Center OIDC service APIs](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/API_Operations.html), an application registers an OAuth 2.0 client and uses one of these flows to obtain an access token that provides permissions to IAM Identity Center protected APIs. An application specifies [access scopes](https://docs.aws.amazon.com/singlesignon/latest/userguide/customermanagedapps-saml2-oauth2.html#scopes-oidc) to declare its intended API user. After you, as the IAM Identity Center administrator, configure your identity source, your application end users must complete a sign-in process, if they have not already done so. Your end users must then provide their consent to allow the application to make API calls. These API calls are made using the users' permissions. In response, IAM Identity Center returns an access token to the application that contains the access scopes to which the users consented.
### Using an OAuth 2.0 grant flow
OAuth 2.0 grant flows are only available through AWS managed applications that support the flows. To use an OAuth 2.0 flow, your instance of IAM Identity Center and any supported AWS managed applications that you use must be deployed in a single AWS Region. Refer to the documentation for each AWS service to determine the regional availability of AWS managed applications and the instance of IAM Identity Center that you want to use.
To use an application that uses an OAuth 2.0 flow, the end user must enter the URL where the application will connect and register with your instance of IAM Identity Center. Depending on the application, as the administrator, you must provide your users with the **AWS access portal URL** or the **Issuer URL** of your instance of IAM Identity Center. You can find these two settings on the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon/) **Settings** page. For additional information about configuring a client application, refer to that application’s documentation.
The end user experience for signing into an application and providing consent depends on whether the application uses the [Authorization Code Grant with PKCE](#auth-code-grant-pkce) or [Device Authorization Grant](#device-auth-grant).
#### Authorization Code Grant with PKCE
This flow is used by applications that run on a device that has a browser.
1. A browser window opens.
1. If the user has not authenticated, the browser redirects them to complete user authentication.
1. After authentication, the user is presented with a consent screen that displays the following information:
+ The name of the application
+ The access scopes that the application is requesting consent to use
1. The user can cancel the consent process or they can give their consent and the application proceeds with access based on the user’s permissions.
#### Device Authorization Grant
This flow can be used by applications that run on a device with or without a browser. When the application initiates the flow, the application presents a URL and a user code that the user must verify later in the flow. The user code is necessary because the application that initiates the flow might be running on a different device than the device on which the user provides consent. The code ensures that the user is consenting to the flow they initiated on the other device.
**Note**
If you have clients using `device.sso.region.amazonaws.com`, you must update your authorization flow to use Proof Key for Code Exchange (PKCE). For more information, see [Configuring IAM Identity Center authentication with the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-sso.html) in the *AWS Command Line Interface User Guide*.
1. When the flow initiates from a device with a browser, a browser window opens. When the flow initiates from a device without a browser, the user must open a browser on a different device and go to the URL that the application presented.
1. In either case, if the user has not authenticated, the browser redirects them to complete user authentication.
1. After authentication, the user is presented with a consent screen that displays the following information:
+ The name of the application
+ The access scopes that the application is requesting consent to use
+ The user code that the application presented to the user
1. The user can cancel the consent process or they can give their consent and the application proceeds with access based on the user’s permissions.
### Access scopes
A *scope* defines the access for a service that can be accessed through an OAuth 2.0 flow. Scopes are a way for the service, also called a resource server, to group permissions related to actions and the service resources, and they specify the coarse-grained operations that OAuth 2.0 clients can request. When an OAuth 2.0 client registers with the [IAM Identity Center OIDC service](https://docs.aws.amazon.com/singlesignon/latest/OIDCAPIReference/Welcome.html), the client specifies the scopes to declare its intended actions, for which the user must provide consent.
OAuth 2.0 clients use `scope` values as defined in [section 3.3 of OAuth 2.0 (RFC 6749)](https://www.rfc-editor.org/rfc/rfc6749.html#section-3.3) to specify what permissions are being requested for an access token. Clients can specify a maximum of 25 scopes when requesting an access token. When a user provides consent during an Authorization Code Grant with PKCE or Device Authorization Grant flow, IAM Identity Center encodes the scopes into the access token it returns.
AWS adds scopes to IAM Identity Center for supported AWS services. The following table lists the scopes that the IAM Identity Center OIDC service supports when you register a public client.
#### Access scopes supported by the IAM Identity Center OIDC service when registering a public client
****
| Scope | Description | Services supported by |
| --- | --- | --- |
| sso:account:access | Access IAM Identity Center managed accounts and permission sets. | IAM Identity Center |
| codewhisperer:analysis | Enable access to Kiro code analysis. | AWS Builder ID and IAM Identity Center |
| codewhisperer:completions | Enable access to Kiro inline code suggestions. | AWS Builder ID and IAM Identity Center |
| codewhisperer:conversations | Enable access to Kiro chat. | AWS Builder ID and IAM Identity Center |
| codewhisperer:taskassist | Enable access to Kiro Agent for software development. | AWS Builder ID and IAM Identity Center |
| codewhisperer:transformations | Enable access to Kiro Agent for code transformation. | AWS Builder ID and IAM Identity Center |
| codecatalyst:read\$1write | Read and write to your Amazon CodeCatalyst resources, allowing access to all your existing resources. | AWS Builder ID and IAM Identity Center |
| verified\$1access:application:connect | Enable AWS Verified Access | AWS Verified Access |
| redshift:connect | Connect to Amazon Redshift | Amazon Redshift |
| datazone:domain:access | Access your DataZone Domain Execution Role | Amazon DataZone |
| nosqlworkbench:datamodeladviser | Create and read data models | NoSQL Workbench |
| transform:read\$1write | Enable access to AWS Transform Agent for code transformation | AWS Transform |
# Setting up customer managed SAML 2.0 applications
If you use customer managed applications that support [SAML 2.0](https://wiki.oasis-open.org/security), you can federate your IdP to IAM Identity Center through SAML 2.0 and use IAM Identity Center to manage user access to those applications. You can select a SAML 2.0 application from a catalog of commonly used applications in the IAM Identity Center console, or you can set up your own SAML 2.0 application.
**Note**
If you have customer managed applications that support OAuth 2.0 and your users need access from these applications to AWS services, you can use trusted identity propagation. With trusted identity propagation, a user can sign in to an application, and that application can pass the users’ identity in requests to access data in AWS services.
**Topics**
+ [Set up an application from the IAM Identity Center application catalog](saasapps.md)
+ [Set up your own SAML 2.0 application](customermanagedapps-set-up-your-own-app-saml2.md)
# Set up an application from the IAM Identity Center application catalog
You can use the application catalog in the IAM Identity Center console to add many commonly used SAML 2.0 applications that work with IAM Identity Center. Examples include Salesforce, Box, and Microsoft 365.
Most applications provide detailed information about how to set up the trust between IAM Identity Center and the application's service provider. This information is available in the configuration page for the application, after you select the application in the catalog. After you configure the application, you can assign access to users or groups in IAM Identity Center as needed.
Use this procedure to set up a SAML 2.0 trust relationship between IAM Identity Center and your application's service provider.
Before you begin this procedure, it is helpful to have the service provider's metadata exchange file so that you can more efficiently set up the trust. If you do not have this file, you can still use this procedure to configure the trust it manually.
**To add and configure an application from the application catalog**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Choose **Applications**.
1. Choose the **Customer managed** tab.
1. Choose **Add application**.
1. On the **Select application type** page, under **Setup preference**, choose **I want to select an application from the catalog**.
1. Under **Application catalog**, start typing the name of the application that you want to add in the search box.
1. Choose the name of the application from the list when it appears in the search results, and then choose **Next**.
1. On the **Configure application** page, the **Display name** and **Description** fields are prepopulated with relevant details for the application. You can edit this information.
1. Under **IAM Identity Center metadata**, do the following:
1. Under **IAM Identity Center SAML metadata file**, choose **Download** to download the identity provider metadata.
1. Under **IAM Identity Center certificate**, choose **Download certificate** to download the identity provider certificate.
**Note**
You will need these files later when you set up the application from the service provider's website. Follow the instructions from that provider.
1. (Optional) Under **Application properties**, you can specify the **Application start URL**, **Relay state**, and **Session duration**. For more information, see [Understand application properties in the IAM Identity Center console](appproperties.md).
1. Under **Application metadata**, do one of the following:
1. If you have a metadata file, choose **Upload application SAML metadata file**. Then, select **Choose file** to find and select the metadata file.
1. If you do not have a metadata file, choose **Manually type your metadata values**, and then provide the **Application ACS URL** and **Application SAML audience** values.
1. Choose **Submit**. You're taken to the details page of the application that you just added.
# Set up your own SAML 2.0 application
You can set up your own applications that allow identity federation using SAML 2.0 and add them to IAM Identity Center. Most of the steps for setting up your own SAML 2.0 applications are the same as setting up a SAML 2.0 application from the application catalog in the IAM Identity Center console. However, you must also provide additional SAML attribute mappings for your own SAML 2.0 applications. These mappings enable IAM Identity Center to populate the SAML 2.0 assertion correctly for your application. You can provide this additional SAML attribute mapping when you set up the application for the first time. You can also provide SAML 2.0 attribute mappings on the application details page in the IAM Identity Center console.
Use the following procedure to set up a SAML 2.0 trust relationship between IAM Identity Center and your SAML 2.0 application's service provider. Before you begin this procedure, make sure that you have the service provider's certificate and metadata exchange files so that you can finish setting up the trust.
**To set up your own SAML 2.0 application**
1. Open the [IAM Identity Center console](https://console.aws.amazon.com/singlesignon).
1. Choose **Applications**.
1. Choose the **Customer managed** tab.
1. Choose **Add application**.
1. On the **Select application type** page, under **Setup preference**, choose **I have an application I want to set up**.
1. Under **Application type**, choose **SAML 2.0**.
1. Choose **Next**.
1. On the **Configure application** page, under **Configure application**, enter a **Display name** for the application, such as **MyApp**. Then, enter a **Description**.
1. Under **IAM Identity Center metadata**, do the following:
1. Under **IAM Identity Center SAML metadata file**, choose **Download** to download the identity provider metadata.
1. Under **IAM Identity Center certificate**, choose **Download** to download the identity provider certificate.
**Note**
You will need these files later when you set up the custom application from the service provider's website.
1. (Optional) Under **Application properties**, you can also specify the **Application start URL**, **Relay state**, and **Session duration**. For more information, see [Understand application properties in the IAM Identity Center console](appproperties.md).
1. Under **Application metadata**, choose **Manually type your metadata values**. Then, provide the **Application ACS URL** and **Application SAML audience** values.
1. Choose **Submit**. You're taken to the details page of the application that you just added.