Note: OCI Identity Domains provide the capabilities of IDCS for new OCI customers effective immediately. For customers who use IDCS currently, the existing IDCS stripes will be migrated to OCI Identity Domains over next several months. Please refer to OCI Identity Domain documentation for more information. This change does not impact the security patterns discussed in this blog. The security features attributed to IDCS in this blog are also provided by OCI Identity Domains.
In my previous post, we saw how using the generic OIDC social provider type may result in an error.
As discussed in that post, the error was occurring since IDCS by default, not only expects email to be part of the UserInfo response from the IDP (AWS Cognito) but also uses email as the identifier for user accounts (“username” attribute) for OIDC flows. Since the user attribute configuration in Cognito did not include email, it does not send email in the UserInfo response: a perfectly valid use case! To get this working, we have to let IDCS know which attribute it should consider as the identifier while receiving UserInfo from the IDP. Since different use cases will require different identifiers, there should be a way in IDCS to customize IDP configurations.
Custom Social Provider Metadata
To allow customers with different use cases, IDCS has taken a novel approach. You can define new social provider types by using a series of declaratives. Each provider type has its own metadata and the IDCS REST API endpoint is used to upload the metada into IDCS. For example, I have uploaded the following metadata into IDCS to address the email issue (only the top snippet is shown; refer to the doc for a complete example).
In the above metadata, I have created a new social provider type called “CognitoNoEmail” (type field). And note the idAttribute which has the value “preferred_username”. This is a powerful construct: we are telling IDCS to use preferred_username instead of (default) email as the identifying attribute in UserInfo. The metadata also includes declaratives for various endpoints such as authorization, etc. Once the above metadata is fed to IDCS, IDCS starts displaying CognitoNoEmail as a distinct OIDC provider type along with the out-of-the-box types, as shown in the following figure:
A new provider can be created using the newly created type:
The new provider is named CognitoNoEmail (same as the type name, for convenience). Adding it to the IDP policies makes it appear on the IDCS sign-in page.
Clicking CognitoNoEmail will take you to Cognito for login.
After authenticating the user, the user will get redirected to IDCS. If the user is not yet registered, IDCS will prompt for registration. Otherwise, the user will be logged into IDCS.
Note the username attribute above: “amitc”. This is the preferred_username of the user in Cognito and is returned in the UserInfo. The Cognito username is also returned.
Summary
IDCS by default uses email as the matching attribute while retrieving user information from an OIDC IDP. If IDP configuration does not include email, then the default OIDC provider template cannot be used. IDCS supports metadata-driven template definitions which can be used to customize OIDC provider creation in IDCS.
To learn more about IDCS, please visit Oracle OCI IAM page.