[enoki-connect] feature request: Support for external idTokens

[reslear]

Currently, Enoki Connect does not accept external identity tokens (idTokens) only oauth2.
This limits integration with providers that only return idTokens or special tokens, such as:

• Facebook Limited Login (iOS) → returns a limited access token (JWT-like structure) instead of a long-lived access token.
• Google Sign-In → returns an idToken as the primary proof of identity.

Without support for these tokens, developers need to implement custom server-side validation and session bridging, which breaks the simplicity of using Enoki for authentication.

[pchrysochoidis]

Hey @reslear, just to clarify:

• is this about Enoki Wallet? (not Enoki Connect)
• are you asking for a way to pass an externally obtained ID token (e.g. from Google or Facebook) directly into Enoki Wallet instead of using its built-in auth flow? Could you share your specific use case?
• would adding an extra (optional) config param to Enoki Wallet, to customise the login/auth flow help with this issue? (a function that would accept the authUrl and return a Promise<JWT> - something similar with what you did here)

[reslear]

hmm... We want ID-token–based auth (OIDC-style): pass an already obtained id_token (e.g., Google id_token or Facebook Limited Login on iOS, which is not classic OAuth2) into Enoki Wallet to create/link the Enoki session.

Our app/back end already verifies the provider token (issuer, audience, expiry, JWKS). We want Enoki to accept that identity proof and mint an Enoki session without re-running its own OAuth flow.

something like :

// 0. call enoki to generate nonce 

// 1. call auth flow with nonce

// 2. geting idToken 

// 3. method to verify with enoki 
await wallet.loginWithIdToken({
  provider: 'google' | 'facebook' | 'facebook_limited',
  nonce,
  token: idTokenString,
});

lower level but not as low as writing your own wallet alternatives, In general, this will help who already have their own authorizations to seamlessly integrate with enoki.

[reslear]

Okay, in general, individual methods are not really necessary, since we can use workarounds #517
I'll close it for now.