[Subtask] Use token exchange for standalone Lance REST outbound identity
- Dominant language
- Java
- Stars
- 3.2k
- Forks
- 935
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 298
Description
### Describe the subtask
Replace raw `Authorization` replay with OAuth 2.0 token exchange (RFC 8693): Lance REST presents its own service identity to the identity provider and obtains a short-lived token issued for the caller with `audience = Gravitino`, then uses that token on the outbound call.
This removes three limits of credential replay: Kerberos callers become forwardable (the exchange happens at Lance REST, where the Negotiate ticket is valid); OAuth tokens no longer need to be valid at both services; and Lance REST holds delegated, scoped, short-lived tokens instead of the caller's original credential.
Depends on an identity provider that supports the exchange grant. The `LanceCallerTokenProvider` introduced for credential forwarding stays as the per-request seam — only `getCustomTokenInfo()` changes from "return the caller's header" to "exchange and return the delegated token". Deployments whose IdP lacks token exchange keep credential replay.
### Parent issue
#13090
Contributor guide
Research direction
Start with the per-request LanceCallerTokenProvider seam introduced for credential forwarding, focusing on getCustomTokenInfo(). Trace how the outbound Lance REST call currently obtains and sends the caller credential. Done means supported identity providers exchange the service identity for a short-lived token with audience=Gravitino, while deployments without token exchange retain credential replay.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api, authentication, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100