fix(oauth): make ed25519 optional and add access_token to AccessTokenResponse#487
Merged
crossle merged 1 commit intoMay 12, 2026
Conversation
…Response
The backend client_secret flow does not use an ed25519 keypair and returns
an access_token JWT instead of a server ed25519 key. Previously, callers
had to cast getToken() as any to pass { client_id, client_secret, code }
and read resp.access_token.
- AccessTokenRequest.ed25519: required → optional
- AccessTokenResponse.ed25519: required → optional
- AccessTokenResponse.access_token: added as optional field
All changes are backward-compatible: existing PKCE callers are unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The backend OAuth flow (using
client_secret) does not use an ed25519 keypair and returns anaccess_tokenJWT in the response — not a servered25519key. However, the existing types forced callers into the PKCE shape:AccessTokenRequest.ed25519was required, blocking{ client_id, client_secret, code }withoutas anyAccessTokenResponsehad noaccess_tokenfield, so callers couldn't read it without a castChanges
Minimal, backward-compatible field changes only — no type renames, no new interfaces:
AccessTokenRequest.ed25519:string→string?(required → optional)AccessTokenResponse.ed25519:string→string?(required → optional)AccessTokenResponse.access_token: added asstring?Before
After
Existing PKCE callers are unaffected — passing
ed25519still works as before.