Remember Lightning Out (Beta)? The early aura-based experiment that seemed to live in beta forever? We used it when we had to, held our breath through CSP errors, and prayed our embedded components wouldn’t suddenly disappear. It was clever, sure, but also clunky, like duct-taping Salesforce UI into other apps. Launched back in 2015, it lingered in beta for nearly a decade. Developers joked it had become Salesforce’s version of vaporware.
But now, in Winter ’26, it’s finally official: Lightning Out 2.0 is here, GA, and worth the wait. With Lightning Out 2.0, Salesforce has officially dragged the concept into the modern, LWC-first era. No Aura, no black-box authentication tricks, just a clean, secure, and standards-based way to take your Lightning Web Components beyond Salesforce.
Lightning Out (Beta) vs. 2.0
| Feature | Lightning Out (Beta) | Lightning Out 2.0 |
|---|---|---|
| Component Type | Primarily Aura. To use Lightning Web Components (LWC) with Lightning Out (Beta), they must be wrapped within an Aura component. | Custom Lightning Web Components (LWC). |
| Status | Beta since 2015. | GA in Winter ’26. |
| Authentication | Requires explicit and manual handling of Salesforce session IDs or OAuth tokens. | Secure OAuth 2.0 flow (Set up Authentication). |
| User Access | Supports both authenticated and unauthenticated users. Enabling unauthenticated access requires enabling Digital Experiences and adding the ltng:allowGuestAccess interface. | Only supports authenticated users for now. (Lightning Out 2.0 Limitations). |
| Setup | Static resources, scripts. | Declarative |
| CSP Support | Painful workarounds. | Trusted Site-based and compliant. |
Why 2.0 Matters
Lightning Out 2.0 finally bridges the gap between Salesforce’s secure platform and the open web. Developers can now embed LWCs directly into React, Angular, or plain HTML apps using standard web components and OAuth.
No Aura dependencies. No Visualforce wrappers. No black magic.
This means your Salesforce components, dashboards, forms, or record lists can now reside naturally within your customer portal or intranet, utilizing the same security model and performance as within Salesforce.
The biggest leap is how authentication works. Lightning Out(Beta) relied on fragile session IDs. Lightning Out 2.0 uses OAuth 2.0 and the new /services/oauth2/singleaccess endpoint.
In other words, your external app requests authorization from Salesforce, receives a token, and exchanges it for a Frontdoor URL. This temporary secure link lets your Lightning Out app render in an iframe without session juggling.
No more leaking session IDs. No more unsafe redirects. It just works.
Supported OAuth 2.0 Flows and Setup
To use Lightning Out 2.0, you must design and implement a supported OAuth 2.0 authorization flow. Lightning Out 2.0 doesn’t support JSON Web Token (JWT)-based access tokens, so the OAuth 2.0 JWT bearer flow is not available.
Likewise, the OAuth 2.0 client credentials flow isn’t supported because it filters out the required OAuth scopes. Otherwise, Lightning Out 2.0 supports any OAuth 2.0 flow in which Salesforce sends a response containing an opaque access token to the external app (Salesforce OAuth 2.0 Flows).
In your Salesforce org, create an External Client App (ECA) with OAuth enabled. Follow the setup instructions here: Create an External Client App and Configure OAuth Settings.
In your ECA, include the following OAuth scopes:
- Manage user data via Web browsers (web), or
- Full access (full).
You can keep the default settings in the Flow Enablement and Security sections.
To obtain a Frontdoor URL at runtime, you can use one of two methods:
- Obtain a Frontdoor URL from the Lightning Out 2.0 endpoint: This is the recommended method. It allows only access to Lightning Out 2.0 resources, requires almost no extra setup, and provides built-in Cross-Origin Resource Sharing (CORS) protection. You must add your external app domain name to the Salesforce CORS allowlist.
- Obtain a Frontdoor URL from the standard UI Bridge API endpoint: This approach requires configuring your own server-side authorization flow for the external app. It offers more fine-grained control and can align with stricter enterprise security requirements.
This new flow ensures OAuth-standard security while maintaining Salesforce’s CSP policies. The Frontdoor URL typically expires after a short duration, ensuring no prolonged exposure.
Gone are the days of copying massive Aura bootstrap code. Now it’s just:
<lightning-out-application
components="c-hello-out"
frontdoor-url="https://myorg.lightning.force.com/secur/frontdoor.jsp?...">
</lightning-out-application>
That’s it. The <lightning-out-application> element does all the heavy lifting, loading scripts, bootstrapping the LWC runtime, and rendering your component inside any modern web page.
It’s no exaggeration to say Lightning Out 2.0 finally makes “Salesforce Anywhere” a reality.
Final Thoughts: The Future of Extending Salesforce
Lightning Out 2.0 is more than a technical upgrade; it’s a mindset shift. It shows Salesforce finally embracing a modern, open, composable web. You no longer need to fight the platform to integrate with it.
Build once. Run anywhere. Securely.
