Learn What’s New with Identity Management for Winter ’24

Learning Objectives

After completing this unit, you’ll be able to:

Collect visitor insight with unique visitor identification and headless flows.
Monitor the effect of OAuth 2.0 Username-Password Flow blocking.
Build a native single sign-on experience in a third-party app.

Important!

In order to maintain your certification, you must complete all five units of this module.

Salesforce Certification

If you hold a Salesforce Architect certification, keep in mind that you need to complete this unit and the other 4 units in this module by the due date to maintain your certification. Another important part of maintaining your certification is ensuring your Trailhead and Webassessor accounts are linked.

Interested in learning more about getting certified? Check out all the Salesforce Architect certifications.

Collect Visitor Insight with Unique Visitor Identification and Headless Flows

Trace your users’ journeys from unknown visitors to fully registered users, and collect valuable insights on the experiences that they prefer. With a new headless flow for guest users, you can build your apps to issue a unique visitor (UVID) when an unknown user first visits your app. If the user logs in or registers, you can pass the UVID into a named user authorization flow.

The UVID gives you context for who the user is and how they’ve interacted with your app, so you can design your apps to remember details like a user’s cookie preferences. And with the help of an analytics tool, you can use the UVID to understand what experiences drive guest users to sign up.

Where: This change applies to LWR, Aura, and Visualforce sites accessed Lightning Experience and Salesforce Classic in Enterprise, Unlimited, and Developer editions. Because Headless Identity APIs are exposed through Experience Cloud, you create and manage your implementation using an Experience Cloud site even though users don’t interact with the site directly.

How: This flow is a variation of the Authorization Code and Credentials Flow. During the guest flow, your app generates a UVID and passes it to Salesforce to ultimately get a guest access token with the UVID minted into it. When a user logs in or registers, you can pass the UVID into a named user authorization flow, carrying the guest user context into a logged-in state.

The guest user flow issues a JSON Web Token (JWT)-based access token. To expose the UVID to a named user flow, the named user flow must also issue a JWT-based access token. You can pass the UVID into the following named user authorization flows.

All variations of the OAuth 2.0 web server flow, including the hybrid web server flow and the hybrid app refresh token flow
All variations of the Authorization Code and Credentials Flow, including the Headless Registration Flow and the Headless Passwordless Login Flow

Monitor the Effect of OAuth 2.0 Username-Password Flow Blocking

For orgs created in Summer ’23 or later, the OAuth 2.0 username-password flow is blocked by default. The username-password flow presents security risks. We recommend using the OAuth 2.0 client credentials flow instead.

Where: This change applies to Lightning Experience and Salesforce Classic in all editions.

Why: The username-password flow is blocked by default in new orgs so that developers can’t use it to build integrations. Blocking this flow is likely to break mobile applications, including those developed by Salesforce, such as the Salesforce mobile app and the Field Service mobile app. Blocking is also likely to break managed packages. You can monitor Login History to confirm if the username-password flow is being used for a connected app in Salesforce. To avoid disruptions from blocking the username-password flow, you can enable the flow.

How: To check if the username-password flow is being used for connected apps in Salesforce, create a Login History view and add the Login Subtype field.

To enable the username-password flow, in OAuth and OpenID Connect Settings, select Allow OAuth Username-Password Flows.

Build a Native Single Sign-On Experience in a Third-Party App

With a new supported parameter for the OAuth 2.0 web server flow and OAuth 2.0 user-agent flows, you can now create native single sign-on experiences in third-party apps. For example, you can natively display a button in your app that allows users to log in with Google. When a user clicks the button, the browser is bounced briefly to Salesforce, then automatically redirected to Google to log in. After the user enters their Google credentials, the browser is again redirected briefly to Salesforce before redirecting back to your app. Both redirects to Salesforce happen automatically, so it feels like the user went straight from your app to Google and back again.

Where: This change applies to Lightning Experience and Salesforce Classic in all editions.

How: Set up single sign-on with an authentication provider or SAML identity provider, and add the provider to your My Domain or Experience Cloud site. Then set up the web server flow or user-agent flow. In the authorization request, include the developer name of your provider in the sso-provider parameter. When Salesforce receives the request, it verifies whether there’s an SSO provider with that name configured for the org or site. If there is, Salesforce initiates the SSO flow and eventually logs the user in.

Looking for Help?

Discover More