feature request: Support RFC 8693 Token Exchange for 3rd party jwt

[cloudfy]

What problem did you meet?

Cannot conduct a RFC 8693 token exchange from a 3rd party JWT.

Example:
Provide a Microsoft Entra Id workload identity as jwt to exchange it for a Logto minted verification.

POST /oidc/token
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&client_id=your-app-id
&subject_token=<entraid-issued-subject-token>
&subject_token_type=urn:ietf:params:oauth:token-type:access_token
&resource=https://your-downstream-service.com
&scope=read

Describe what you'd like Logto to have

Provide option to configure token exchange configurations, allowing 3rd party token, allowing Logto to support RFC 8693 Token Exchange.

• Logto must configure jwks or similar trust.
• Logto could configure token exchange subject mapping.
• Logto cloud configure to import the new [sub] as a user or entity.

[xiaoyijun]

Hi @cloudfy , thanks for your request.

Could you share a bit more about the problem or business scenario you’re trying to solve? That would help us better evaluate the request and understand whether this fits Logto.

[cloudfy]

Imagine a fintech company, PayFlow, that offers payment processing services to merchants. They integrate with a third-party identity provider, Logto, and also collaborate with an external fraud detection service, RiskShield.

Problem

A merchant logs into PayFlow using Logto and gets an access token issued by Logto.

Now PayFlow needs to call RiskShield’s API on behalf of that user but RiskShield doesn’t trust Logto tokens directly.

Solution: RFC 8693 Token Exchange

This is where RFC 8693 (OAuth 2.0 Token Exchange) comes in smooth, elegant, and honestly a bit charming in how it bridges trust boundaries.