Headless Identity on Salesforce: OAuth 2.0 for Custom Front Ends

This is Part 6 of Vantage Point's Headless 360 series. Part 1, "Salesforce Headless 360: Architecture and Readiness Guide," covers the architecture, availability, and governance model. Earlier parts cover the developer platform, the admin's day-to-day view, HXL and Mosaic, and headless commerce. This final part answers the question every custom front end raises: how do users log in?

With Dreamforce weeks away, the Headless 360 conversation tends to focus on agents, MCP servers, and experience layers. But none of those experiences work for customer-facing apps until identity does. If you are building a mobile app, single-page app, or partner portal on your own stack, Salesforce Headless Identity lets you keep full control of the user experience while Salesforce handles authentication behind the scenes. This guide covers what it is, how its OAuth 2.0 flows work, what setup involves, and what security teams should plan for.

Quick Answer

Salesforce Headless Identity separates back-end authentication from front-end identity experiences. Your custom app — a single-page app, mobile app, or third-party portal — renders its own login, registration, and password-reset screens, while Salesforce Customer Identity authenticates through Headless Identity APIs. Login is built on the OAuth 2.0 Authorization Code and Credentials Flow, with PKCE strongly recommended for browser-based apps. The full path is in Salesforce's Headless Identity Implementation Guide.

TL;DR

• What it is: Salesforce APIs — Headless Login, Headless Registration, and Headless Forgot Password — that let custom front ends authenticate users without a Salesforce-hosted login page.
• Why it matters: Customer-facing apps get complete UI control while accounts, contacts, and access management stay in Salesforce.
• How it works: The Authorization Code and Credentials Flow, built on the OAuth 2.0 Authorization Code grant type, with PKCE for public clients.
• Prerequisites: An Experience Cloud site (even if users never see it), an external client app, a demo profile, and CORS configuration.
• How Vantage Point helps: Senior consultants design the identity architecture, OAuth flows, and security model so your custom front end launches on solid ground.

What Is Salesforce Headless Identity?

Salesforce Headless Identity separates back-end authentication from front-end identity experiences: you call Headless Identity APIs to use Salesforce Customer Identity for authentication while keeping complete control over the user experience in an off-platform or third-party app. As the implementation guide describes, Salesforce offers three Headless Identity features — login (Headless Login API), registration (Headless Registration API), and password reset (Headless Forgot Password API) — plus the ability to link a single sign-on (SSO) provider for a native SSO experience.

Salesforce frames Headless Identity use cases in two categories:

That second row surprises many teams: even for a standalone app, you still create and configure an Experience Cloud site. Users never interact with it, but it is the container through which the APIs are exposed and where customer identity data lives. Headless Identity is available in Enterprise, Unlimited, and Developer Editions.

How Does the Authorization Code and Credentials Flow Work?

Headless login is configured via the Authorization Code and Credentials Flow, built on the OAuth 2.0 Authorization Code grant type. The Headless Login Overview walks through the flow for a single-page app:

1. Your user enters credentials in your app. Your login form is natively displayed — no Salesforce-branded page, no redirect away.
2. PKCE values are generated. If you use the Proof Key for Code Exchange extension, the app generates values to verify the authorization code. Salesforce strongly recommends always using PKCE for single-page apps.
3. Your app sends a headless authorization request. Client-side JavaScript calls the Headless Login API authorization endpoint on your Experience Cloud site.
4. Salesforce returns a 302 redirect with an authorization code to a preconfigured callback URL. Single-page apps can use Salesforce's OAuth 2.0 echo endpoint instead of building their own callback endpoint.
5. The callback endpoint extracts the code and returns it to the app, which exchanges the code for an access token with a POST request to the token endpoint.
6. Salesforce validates the request and returns an access token. Your app processes the token and creates the user's session.
7. The user is logged in. Your app now makes authenticated requests to protected Salesforce endpoints — Salesforce APIs, custom Apex REST services, or Data 360 — and the user sees their data inside your experience.

If your team knows OAuth 2.0, the shape is familiar — the difference is that the exchange happens inside your UI.

What About Registration, Password Reset, and Single Sign-On?

Login alone is not a complete identity experience. Salesforce's headless coverage extends to the full lifecycle:

• Headless Registration. The Headless Registration Flow extends the Authorization Code and Credentials Flow. At the end, a new user is registered and logged in, with access to Salesforce data — account creation never bounces the user to a separate Salesforce page.
• Headless Forgot Password. The Headless Forgot Password Flow handles resets inside your app — plan for it from day one.
• Native SSO. You can configure the OAuth 2.0 web-server and user-agent flows to create a native single sign-on experience, linking an external identity provider so users authenticate with credentials they already have.

Together, these capabilities mean the entire identity journey — registration, login, recovery, and federated sign-in — can live inside your front end while Salesforce remains the system of record.

How Do You Set Up Headless Identity?

The implementation guide's setup path is methodical, and order matters:

1. Complete the prerequisites. Create a role to manage Headless Identity features and assign yourself the Headless Identity admin role, per the prerequisites page.
2. Set up a demo profile for end users. Profiles define how end users access data in Salesforce; new users are automatically assigned to this profile when they register. Salesforce recommends cloning a standard profile — Customer Community User, Customer Community Plus User, External Identity User, Partner Community User, or Partner User — so users can log in via Experience Cloud. The demo profile setup walks through cloning Customer Community User into a "Headless Demo Profile" for testing as an end user.
3. Configure CORS. Your app's JavaScript calls Salesforce endpoints from a browser, so cross-origin resource sharing must allow your app's domain.
4. Create an account for end users and enable the Authorization Code and Credentials Flow.
5. Implement reCAPTCHA on web apps to protect public-facing registration and login endpoints from abuse.
6. Set up the Experience Cloud site that exposes the Headless Identity APIs and stores customer accounts and contacts.
7. Set up an external client app with the policies that govern your headless app's access, per the external client app configuration.
8. Test with Postman and JavaScript examples. Salesforce maintains a Headless Identity API demo collection in its Postman workspace, and the guide includes JavaScript examples — both shorten the path to a working first call.

For a structured introduction, the Trailhead module Headless Identity Basics covers the headless approach, key concepts, features, and guest user identity in about 40 minutes.

How Does Headless Identity Fit Into Headless 360?

Headless 360, as covered in Part 1 of this series and in Salesforce's announcement, makes the entire platform available without a browser — data, logic, experiences, and identity. Headless Identity is the identity slice: how the users of your custom experiences authenticate when there is no Salesforce UI in the loop. Two connections matter for architects:

• It complements the agent and MCP story. Earlier parts of this series cover how agents and developers reach Salesforce through MCP servers, HXL, and commerce APIs. Those patterns govern system and agent access; Headless Identity governs end-user access — the customer logging into your mobile app, the partner registering on your portal. A complete headless architecture usually needs both.
• It shares the same governance posture. Headless Identity requests run as an authenticated identity, and profiles, permission sets, and field-level security still determine what data comes back. The Headless 360 Developer Center is the best hub for tracking how these surfaces evolve as Dreamforce announcements land.

What Security Considerations Should Architects Plan For?

Headless Identity requires genuine OAuth 2.0 expertise — you are building and maintaining a custom front end that talks directly to Salesforce's identity endpoints. You get full control, and you own the security of the experience. Plan for these areas:

• Always use PKCE for public clients. Single-page and mobile apps cannot keep a client secret; PKCE protects the code exchange, and Salesforce strongly recommends it.
• Scope profiles narrowly. New registrants are automatically assigned the profile you configure. Clone the most restrictive standard profile that fits, then grant only what the app needs.
• Protect public endpoints. Registration and forgot-password endpoints are internet-facing by design. reCAPTCHA, rate limiting, and monitoring are not optional.
• Design token handling deliberately. Decide where access and refresh tokens live, how sessions expire, and how revocation works on logout or device loss.
• Plan CORS and callback URLs precisely. Overly broad CORS allowlists and wildcard redirect URIs are common sources of avoidable exposure.
• Treat the hidden Experience Cloud site as production infrastructure. Users may never see it, but it stores customer accounts and mediates every login — include it in change management and monitoring.

What Should Teams Do Before Dreamforce?

1. Read the Headless Identity Implementation Guide — the canonical reference for the full build.
2. Earn the Headless Identity Basics badge to align your team on concepts and terminology.
3. Fork the Postman demo collection and make real calls against a Developer Edition org.
4. Prototype the login flow in a sandbox with a cloned demo profile, PKCE enabled, and the OAuth 2.0 echo endpoint as your callback.
5. Map your identity requirements — registration, password reset, SSO, guest access — against the headless capabilities so gaps surface early.
6. Review the series hub for the availability and governance context that shapes what your edition supports, and bring your architecture questions to Dreamforce.

How Vantage Point Helps

Vantage Point helps teams design and deliver headless identity architectures that hold up in production: selecting the right OAuth 2.0 flows, scoping profiles and external client app policies, hardening public endpoints, and connecting identity to your Salesforce implementation and advisory and system integration and data migration strategy. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver.

FAQ

What is Salesforce Headless Identity?

Headless Identity is a set of Salesforce APIs that separate back-end authentication from front-end identity experiences. It includes the Headless Login API, Headless Registration API, and Headless Forgot Password API, plus native SSO support — custom apps control the user experience while Salesforce Customer Identity handles authentication.

Which OAuth 2.0 flow does Salesforce headless login use?

Headless login uses the Authorization Code and Credentials Flow, built on the OAuth 2.0 Authorization Code grant type. Your app sends a headless authorization request, receives an authorization code via a 302 redirect to a callback endpoint, and exchanges the code for an access token.

Do I need an Experience Cloud site to use Headless Identity?

Yes. Headless Identity APIs are exposed and configured through Experience Cloud, and the site stores your customer accounts and contacts. Even for standalone apps where users never see a Salesforce page, you still create and configure a site behind the scenes.

Is PKCE required for headless login?

PKCE is technically optional but strongly recommended by Salesforce for single-page apps. Public clients like browser and mobile apps cannot protect a client secret, so PKCE's code verifier protects the exchange from interception.

Can users register and reset passwords without seeing a Salesforce page?

Yes. The Headless Registration Flow extends the login flow so new users register and log in inside your app, and the Headless Forgot Password Flow handles resets natively. You can also add SSO through an external identity provider via the OAuth 2.0 web-server or user-agent flows.

How does Headless Identity relate to Salesforce Headless 360?

Headless Identity is the identity layer of the broader Headless 360 vision — the whole platform, from data to experiences, available without a browser. Where MCP servers and HXL govern agent and system access, Headless Identity governs end-user authentication for custom front ends.

Building a custom front end on Salesforce? Whether you are prototyping a headless login flow, designing an identity architecture, or planning your Headless 360 roadmap ahead of Dreamforce, Vantage Point's senior consultants can help you get identity right the first time. Contact Vantage Point to schedule a Headless 360 readiness session, or explore our Salesforce services to see how we support development teams end to end.

Vantage Point is a boutique CRM consulting firm helping businesses transform with Salesforce, HubSpot, and AI — 150+ clients, 400+ engagements, and a 4.71/5 average engagement rating. Learn more at vantagepoint.io.