React Native SDK doesn't support `custom-jwt` authentication type
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Stale
- Tech stack
- react-native, typescript
- Domain
- authentication, mobile
Research direction
Start in the React Native SDK's client.ts, reading validAuthenticatingTypes alongside completeAuthWithBundle and submitJwt. Reproduce authenticateAsync with type "custom-jwt" and confirm the flow no longer reports "Unsupported authenticating type" after the supported authentication types are aligned.
Written by the indexing model from the issue text.
Description
React Native SDK doesn't support custom-jwt authentication type
Environment
- Package:
@account-kit/react-native-signerversion4.66.2 - Platform: React Native
- Comparison: Web SDK (
@account-kit/react) v4.65.0+ supportscustom-jwtauthentication
Description
The React Native SDK has a complete implementation of JWT authentication via the submitJwt method, but the authentication flow fails at runtime because "custom-jwt" is not included in the validAuthenticatingTypes array.
Current Behavior
When attempting to authenticate with a custom JWT using the following code:
await authenticateAsync({
type: "custom-jwt",
jwt: idToken,
});
The authentication fails with the error:
Error: Unsupported authenticating type
Root Cause
In node_modules/@account-kit/react-native-signer/src/client.ts at line 72-76:
private validAuthenticatingTypes: AuthenticatingEventMetadata["type"][] = [
"email",
"otp",
"oauth",
];
The completeAuthWithBundle method (line 189-191) validates the authentication type:
if (!this.validAuthenticatingTypes.includes(params.authenticatingType)) {
throw new Error("Unsupported authenticating type");
}
However, the submitJwt method (lines 167-179) is fully implemented and uses "custom-jwt":
override async submitJwt(
args: Omit<JwtParams, "targetPublicKey">,
): Promise<JwtResponse> {
this.eventEmitter.emit("authenticating", { type: "custom-jwt" });
const publicKey = await this.stamper.init();
return this.request("/v1/auth-jwt", {
jwt: args.jwt,
targetPublicKey: publicKey,
authProvider: args.authProvider,
expirationSeconds: args.expirationSeconds,
});
}
Expected Behavior
The "custom-jwt" authentication type should be supported in React Native, just as it is in the Web SDK.
Proposed Fix
Add "custom-jwt" to the validAuthenticatingTypes array:
private validAuthenticatingTypes: AuthenticatingEventMetadata["type"][] = [
"email",
"otp",
"oauth",
"custom-jwt", // Add this
];
Use Case
We are implementing a unified authentication flow where users:
- Authenticate with our OAuth provider (OIDC-compliant)
- Receive an ID token with a nonce generated from the Account Kit
targetPublicKey - Use that ID token to authenticate with Account Kit via custom JWT
This pattern is documented in the Alchemy docs:
https://www.alchemy.com/docs/wallets/authentication/login-methods/bring-your-own-auth
The Web SDK supports this flow perfectly, but React Native requires a workaround using type assertions to bypass the validation check.
Current Workaround
await authenticateAsync({
type: "custom-jwt" as unknown as "email",
jwt,
} as any);
This bypasses TypeScript type checking and the runtime validation, but it's not ideal and requires disabling linter rules.
Additional Context
All the infrastructure for custom JWT authentication already exists in the React Native SDK:
- ✅
submitJwtmethod is implemented - ✅ Backend API endpoint
/v1/auth-jwtis called - ✅ Event emission works correctly
- ❌ Only the validation array is missing
"custom-jwt"
This appears to be an oversight rather than an intentional limitation.
Impact
This prevents React Native developers from using the "Bring Your Own Auth" feature that is available in the Web SDK, limiting authentication options for mobile applications.
- Dominant language
- TypeScript
- Stars
- 321
- Forks
- 231
- Avg merge
- 43m
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from alchemyplatform/aa-sdk
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
alchemyplatform/aa-sdk#1541 ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
alchemyplatform/aa-sdk#2567 · 2 comments ·
-
bug
Difficulty 5/5 Over a week Newbie friendliness 20/100
alchemyplatform/aa-sdk#2553 ·
-
documentation
Difficulty 5/5 Over a week Newbie friendliness 15/100
alchemyplatform/aa-sdk#2547 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
alchemyplatform/aa-sdk#2478 ·
All issues in alchemyplatform/aa-sdk
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100