Add Third-Party Applications documentation by dlozlla · Pull Request #870 · auth0/docs-v2

dlozlla · 2026-03-31T17:00:23Z

Description

Adds documentation for Third-Party Applications EA R1, launching with the Auth for MCP GA announcement (April 30, 2026).

7 new pages:

Third-Party Applications — Overview with get-started flow, use cases (partner integrations, AI agents/MCP, developer ecosystems, XAA)
Security Considerations — OAuth 2.1 alignment, explicit API authorization, restricted client config, unsupported features, RT defaults, redirect protection, /authorize parameter validation
Configure Third-Party Applications — Step-by-step: create app (Dashboard + API), configure default and per-app API permissions, promote connections, DCR
Troubleshooting — 14 error scenarios with causes and solutions
Permissive Mode — Backward compatibility for pre-existing customers, feature comparison, migration path
User Consent — Moved to Applications level (covers both 1P and 3P consent). Added OAuth consent intro, replaced localhost box with app impersonation link, kept password-based flows
First-Party and Third-Party Applications — Rewritten as strict-only conceptual bridge. Absorbs ownership pages. Promoted from Confidential/Public subgroup to top level

10 existing pages updated:

docs.json — New Third-Party Applications group, 1P/3P promoted, Confidential/Public trimmed, User Consent at Applications level
confidential-and-public-applications — Orthogonality callout, updated links
application-access-to-apis-client-grants — New "Default permissions for third-party applications" section
api-access-policies-for-applications — 1P vs 3P access policy table, default permissions via Dashboard
application-grant-types — Third-party restrictions table
dynamic-client-registration — "DCR and third-party applications" section
application-settings — Restricted properties callout
set-up-database-connections / update-application-connections — Domain-level connection callouts
promote-connections-to-domain-level — Rewritten intro for 3P context

Placeholders for screenshots (5), code snippets (4) marked with [SCREENSHOT PLACEHOLDER] and [CODE PLACEHOLDER].

Redirects needed (not configured in this PR): old paths under confidential-and-public-applications/ for removed pages (enable-third-party-applications, view-application-ownership, update-application-ownership, old user-consent URL, old
first-party-and-third-party URL).

References

JIRA: ROAD-7640 (EA Release 1 for Auth for MCP GA)
Information Architecture spec: Confluence — Public Docs
Release strategy: Confluence — Secure-By-Default Release Strategy
Deprecation comms (separate deliverable): Confluence — Deprecation Communications
Migration guide (separate deliverable): Confluence — Migration Guide

Testing

Run cd main && mintlify dev (requires Node.js v20)
Navigate to Get Started > Applications in Auth0
Verify navigation: Confidential/Public (trimmed), 1P/3P article (top-level), Third-Party Applications group (5 pages), User Consent (top-level)
Verify all internal links resolve (no 404s within the new/updated pages)
Review placeholder locations — search for [SCREENSHOT PLACEHOLDER] and [CODE PLACEHOLDER]

Checklist

I've read and followed CONTRIBUTING.md.
I've tested the site build for this change locally.
I've made appropriate docs updates for any code or config changes.
I've coordinated with the Product Docs and/or Docs Management team about non-trivial changes.

New pages: - Third-Party Applications overview - Security Considerations - Configure Third-Party Applications - Troubleshooting - Permissive Mode - User Consent (moved to Applications level) - First-Party and Third-Party Applications (rewritten, promoted) Updated pages: - docs.json navigation - Confidential/Public, Client Grants, API Access Policies - Grant Types, DCR, Application Settings - DB Connections, App Connections, Promote Connections Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

Add the deprecation migration guide as a new article under deprecations-and-migrations, with a summary entry in the overview page and navigation in docs.json. Co-Authored-By: Claude <noreply@anthropic.com>

CharlesRea · 2026-04-01T08:40:45Z

Whilst we're here - this page is already very long; could we use separate tabs for the Configure API application access policy section above for Dashboard vs API? Currently I feel the 3P content gets lost at the bottom.

CharlesRea · 2026-04-01T08:45:05Z

In Grant Types section: Available grant types are based on the application type. -> Available grant types are based on the application type and application ownership.

CharlesRea · 2026-04-01T08:47:02Z

Application Properties section - consider if we should explain app ownership briefly and link out to relevant page (since we show app ownesrhip in this section in the dashboard)

CharlesRea · 2026-04-01T08:47:44Z

We are adding new configuration around redirection handling that will need to be added here

CharlesRea · 2026-04-14T09:33:37Z

+
+To configure baseline permissions for all third-party applications, set up [default permissions for third-party applications](/docs/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications).
+
+<Tabs><Tab title="Auth0 Dashboard">


We're missing closing tags for Tabs and Tab here (looks like this renders incorrectly currently)

CharlesRea · 2026-04-14T09:41:42Z

+| **Require Client Grant** | Requires client grant | Requires client grant |
+| **Deny** | Access denied | Access denied |
+
+To configure baseline permissions for all third-party applications, set up [default permissions for third-party applications](/docs/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications).


I think a better link is this one: /docs/get-started/applications/third-party-applications/configure-third-party-applications#configure-api-access-policies (the current linked page just links here in the end to explain how to configure).

But it seems we are somewhat duplicating the docs here bleow, with just the UI docs. Do we want to include the API docs below as well, or just link out to this page only?

(I think having it in both places is indeed useful, as this page is actually the first place I would expect to find this info)

CharlesRea · 2026-04-14T10:01:44Z

+- Authentication errors display an error page instead of redirecting to the application.
+- Email templates (email verification, password reset, user blocked) will not have access to `{{ application.callback_domain }}`, so a fallback must be configured alongside any use of `{{ application.callback_domain }}`. For example:
+
+```liquid wrap lines


Correct syntax looks like this:

{% if application.callback_domain == '' %}https://YOUR_FALLBACK_DOMAIN{% endif %}{% if application.callback_domain != '' %}{{ application.callback_domain }}/result-page{% endif %}

CharlesRea · 2026-04-14T10:20:21Z

+### `invalid_request` for OIDC scopes
+
+**Cause**: OIDC scopes (`openid`, `profile`, `email`) are not available for third-party applications in this release.
+
+**Solution**: Remove OIDC scopes from your authorization request and use API scopes only. OIDC support for third-party applications is planned for a future release.


We won't error, we will just not return OIDC response:

Suggested change

### `invalid_request` for OIDC scopes

**Cause**: OIDC scopes (`openid`, `profile`, `email`) are not available for third-party applications in this release.

**Solution**: Remove OIDC scopes from your authorization request and use API scopes only. OIDC support for third-party applications is planned for a future release.

### No ID token returned from `/oauth/token` endpoin.

**Cause**: OIDC is not available for third-party applications in this release. OIDC scopes (`openid`, `profile`, `email`) are not returned in access tokens

**Solution**: Remove OIDC scopes from your authorization request and use API scopes only. OIDC support for third-party applications is planned for a future release.

CharlesRea · 2026-04-14T10:21:00Z

+
+**Solution**: Update your email templates with a Liquid conditional that provides a fallback for third-party applications:
+
+```liquid wrap lines


Correct syntax looks like this:

{% if application.callback_domain == '' %}https://YOUR_FALLBACK_DOMAIN{% endif %}{% if application.callback_domain != '' %}{{ application.callback_domain }}/result-page{% endif %}

CharlesRea · 2026-04-14T10:22:37Z

+
+Third-party applications in permissive mode behave similarly to first-party applications in terms of available features:
+
+- All grant types are available (authorization code, implicit, client credentials, password, device code)


Password is not supported for permissive 3P apps

Co-Authored-By: Claude <noreply@anthropic.com>

semgrepcode-auth0 · 2026-04-21T18:54:06Z

Semgrep found 2 ssc-4759c514-b537-20ef-d52f-ebb0a5c388fa findings:

universal-components/pnpm-lock.yaml
- L2471 - Triage
- L2474 - Triage

Risk: Affected versions of axios are vulnerable to Improper Neutralization of CRLF Sequences in HTTP Headers ('HTTP Request/Response Splitting') / Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') / Server-Side Request Forgery (SSRF). Axios can be used as a gadget for header injection: if another dependency enables prototype pollution, polluted properties can be merged into Axios request headers and written without CRLF sanitization, allowing request smuggling/SSRF that can reach internal services such as AWS IMDSv2 and potentially lead to credential theft or broader compromise.

Fix: Upgrade this library to at least version 1.15.0 at docs-v2/universal-components/pnpm-lock.yaml:2474.

Reference(s): GHSA-fvcv-3m26-pcqx, CVE-2026-40175

Semgrep found 2 ssc-5ea2c631-7cef-a4e0-e641-d179af079827 findings:

universal-components/pnpm-lock.yaml
- L2471 - Triage
- L2474 - Triage

Risk: Affected versions of axios are vulnerable to Server-Side Request Forgery (SSRF) / Unintended Proxy or Intermediary ('Confused Deputy'). Axios does not normalize hostnames before applying NO_PROXY, so requests to loopback or internal hosts such as localhost. or [::1] can be sent through a configured proxy instead of bypassing it. If an attacker can influence request URLs, they may force local/internal Axios traffic through an attacker-controlled proxy, undermining SSRF protections and exposing sensitive responses.

Manual Review Advice: A vulnerability from this advisory is reachable if you have NO_PROXY configured in your environment

Fix: Upgrade this library to at least version 1.15.0 at docs-v2/universal-components/pnpm-lock.yaml:2474.

Reference(s): GHSA-3p68-rc4w-qgx5, CVE-2025-62718

dlozlla requested review from a team as code owners March 31, 2026 17:00

dlozlla marked this pull request as draft March 31, 2026 17:01

BcnCarlos requested a review from lrzhou25 April 1, 2026 09:20

lrzhou25 added 2 commits April 6, 2026 15:19

feat: 3P EA1 docs review

7740744

Edits and updated references

7b7cece

mintlify Bot deployed to staging - main April 7, 2026 16:31 View deployment

dlozlla and others added 7 commits April 7, 2026 20:26

Add migration guide for Enhanced Security for Third-Party Applications

1c79b73

Add the deprecation migration guide as a new article under deprecations-and-migrations, with a summary entry in the overview page and navigation in docs.json. Co-Authored-By: Claude <noreply@anthropic.com>

Docs review of remaining 3P docs minus migration guide

bc7e323

Copyedited migration guide

454095d

Second pass at 3P docs

44c6624

third review

d209373

Miguel's feedback

b5e4910

add missing curls and screenshots plus DCR refactor

4de05bf

CharlesRea reviewed Apr 14, 2026

View reviewed changes

dlozlla and others added 5 commits April 15, 2026 17:32

changes from Charle's review

6344633

fix remaining comments

9861178

use tabs for api access permissions config

f4eea23

Reviewed 3P app docs

b4741f8

Co-Authored-By: Claude <noreply@anthropic.com>

Final updates

36030bd

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Third-Party Applications documentation#870

Add Third-Party Applications documentation#870
dlozlla wants to merge 15 commits intoauth0:mainfrom
dlozlla:feat/StrictThirdPartyApps

dlozlla commented Mar 31, 2026

Uh oh!

CharlesRea Apr 1, 2026

Uh oh!

CharlesRea Apr 1, 2026

Uh oh!

CharlesRea Apr 1, 2026

Uh oh!

CharlesRea Apr 1, 2026

Uh oh!

CharlesRea Apr 14, 2026

Uh oh!

CharlesRea Apr 14, 2026

Uh oh!

CharlesRea Apr 14, 2026

Uh oh!

CharlesRea Apr 14, 2026

Uh oh!

CharlesRea Apr 14, 2026

Uh oh!

CharlesRea Apr 14, 2026

Uh oh!

semgrepcode-auth0 Bot commented Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		To configure baseline permissions for all third-party applications, set up [default permissions for third-party applications](/docs/get-started/applications/application-access-to-apis-client-grants#default-permissions-for-third-party-applications).

		<Tabs><Tab title="Auth0 Dashboard">


		Solution: Update your email templates with a Liquid conditional that provides a fallback for third-party applications:

		```liquid wrap lines


		Third-party applications in permissive mode behave similarly to first-party applications in terms of available features:

		- All grant types are available (authorization code, implicit, client credentials, password, device code)

Conversation

dlozlla commented Mar 31, 2026

Description

References

Testing

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

semgrepcode-auth0 Bot commented Apr 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants