Free Salesforce Platform Identity and Access Management Architect Practice Test Questions

Explanation:

In this scenario, UC wants to:
Store user credentials in AWS (so AWS is the identity source).
Allow users to access Salesforce for internal operations using those AWS-stored credentials.

This means AWS will act as the Identity Provider (IdP), and Salesforce will be the Service Provider (SP) that trusts AWS to authenticate users. To integrate an external IdP (AWS) with Salesforce for user authentication and authorization, you configure the external IdP as an OpenID Connect (OIDC) Provider in Salesforce. This allows Salesforce to accept OIDC tokens from AWS and map them to Salesforce users for Single Sign-On (SSO).

Analysis of Other Options
Create a custom external authentication provider: This is a misdirection. While you do create an Authentication Provider in Salesforce, it is not "custom" in the sense of building a new authentication system. Instead, you configure a standard OpenID Connect Authentication Provider in Salesforce and point it to AWS Cognito or another OIDC-compliant service.

Develop a custom Auth server in AWS: This approach is unnecessary and overly complex. AWS already provides managed identity services such as Amazon Cognito, which fully supports OpenID Connect. There is no need to build a custom authorization server when a standards-based solution already exists.

Configure the custom employee app as a connected app: A Connected App in Salesforce is used when Salesforce acts as the Identity Provider or when external applications need API access. In this case, AWS is the Identity Provider, so the employee app does not need to be configured as a Connected App for authentication into Salesforce. Instead, Salesforce must be configured to trust AWS.

Conclusion
The correct approach is to configure AWS (using Cognito User Pools) as an OpenID Connect Provider in Salesforce Authentication Provider settings. This establishes AWS as the identity source and allows users stored in AWS to authenticate seamlessly into Salesforce using Single Sign-On.

Reference
Salesforce Help: Set Up an OpenID Connect Authentication Provider
Salesforce Identity Implementation Guide: Authentication Providers for inbound SSO

Explanation:

Let’s analyze the requirement and each option:

Requirement: UC wants to secure Salesforce APIs while leveraging an existing SAML configuration that already supports their single sign-on (SSO) process to Salesforce.

Option B - OAuth 2.0 SAML Bearer Assertion Flow (Correct)
This flow allows a client application to obtain an OAuth access token by presenting a valid, signed SAML assertion that was issued by the company's existing SAML Identity Provider (IdP). Since UC already has a SAML configuration for SSO, this flow reuses that same IdP and trust relationship. The app gets a SAML assertion from the existing IdP, sends it to Salesforce's OAuth token endpoint, and receives an OAuth access token to call APIs. This perfectly fulfills the requirement of securing APIs using the existing SAML infrastructure.

Option A - OAuth 2.0 JWT Bearer Flow (Incorrect)
This flow uses a JSON Web Token (JWT) signed with a certificate, not a SAML assertion. While it is a valid OAuth flow for server-to-server integration, it does not leverage an existing SAML configuration. It requires separate certificate management and does not reuse the SAML SSO IdP.

Option C - OAuth 2.0 User-Agent Flow (Incorrect)
This flow is designed for client-side applications (like JavaScript SPAs or mobile apps) where the OAuth process runs entirely in the user agent (browser). It does not involve SAML at all and does not leverage an existing SAML configuration. It's typically used for browser-based apps that can't securely store a client secret.

Option D - SAML Assertion Flow (Incorrect)
"SAML Assertion Flow" is not a standard OAuth 2.0 authorization grant type defined in the Salesforce OAuth specification. The official name is OAuth 2.0 SAML Bearer Assertion Flow (sometimes called SAML 2.0 Bearer Assertion Flow for OAuth 2.0). This option appears to be a distractor that sounds similar but is not the precise technical term.

Summary
The OAuth 2.0 SAML Bearer Assertion Flow is purpose-built exactly for this scenario: it bridges SAML and OAuth, allowing an organization to reuse its existing SAML IdP investment to secure API access via OAuth tokens.

Reference
Salesforce Help: OAuth 2.0 SAML Bearer Assertion Flow — "Use this flow to get an access token using a SAML assertion when you already have a SAML single sign-on configuration."
Salesforce Developer Documentation: OAuth 2.0 SAML Bearer Assertion Flow — "This flow allows use of a SAML 2.0 identity provider to authorize API access to Salesforce."