Built-in Auth
Replyke manages the full user lifecycle: sign-up, sign-in, and password reset using email and password. No external auth system needed.
OAuth
Sign in with Google, GitHub, Apple, or Facebook. Supports linking multiple providers to one account.
External Auth
Your backend signs a JWT. Replyke verifies it and creates or matches a user automatically. Keep your existing auth stack.
Token Model
All three auth modes produce the same token pair: an access token and a refresh token.| Token | Lifetime | Purpose |
|---|---|---|
| Access token | 30 minutes | Sent with every API request in the Authorization: Bearer header |
| Refresh token | 30 days | Used to obtain a new access token when the current one expires |
A 30-second grace period allows two requests that race to refresh the same token (e.g., two browser tabs loading simultaneously) to both succeed. The first request rotates the token; a second request arriving within that window receives the successor token instead of a reuse error.
Built-in Auth
Replyke provides a complete email/password authentication system out of the box. Use it when you do not have an existing user identity system and want Replyke to manage everything. What it includes:- User sign-up with email and password
- Sign-in returning an access token + refresh token + user object
- Sign-out (revokes the refresh token)
- Password change (requires current password)
- Password reset via email link (requires an email provider configured in the dashboard)
External Auth
Use this model when your application already has its own user management system (Supabase Auth, Auth0, Firebase Auth, NextAuth, a custom system, or anything else) and you want Replyke to associate its data with those users — without rebuilding auth.How It Works
Generate a JWT key pair in the dashboard
Replyke generates an RSA key pair (RS256) for your project. The public key is stored in Replyke. The private key is shown to you once — store it securely as a server-side environment variable. If it is lost or compromised, generate a new key pair from the dashboard.
Sign a JWT on your server when a user logs in
When your application detects a logged-in user, make a request to your own backend. Your backend signs a JWT with your private key and returns it to the client.The JWT payload must include:
The
The signed JWT is safe to pass to the client — it cannot be tampered with because the signature covers the payload using your private key.
| Claim | Value |
|---|---|
sub | Your external user ID (string) |
iss | Your Replyke project ID |
userData | Object with user profile fields (see below) |
userData object can include:| Field | Type | Notes |
|---|---|---|
email | string | Optional but recommended |
name | string | Display name |
username | string | Unique per project |
avatar | string | URL of the user’s profile picture |
bio | string | Short bio |
location | string | User’s location |
birthdate | string | ISO 8601 date |
metadata | object | Public custom data |
secureMetadata | object | Private custom data (not exposed to other users) |
Pass the JWT to Replyke
Pass the signed JWT to
ReplykeProvider via the signedToken prop (SDK), or call the verify external user API endpoint directly.Replyke verifies the JWT against the project’s stored public key. If valid, it looks up the user by the sub claim. If the user does not exist, it is created from the userData fields. If the user already exists, their profile fields are updated if anything has changed.On success, Replyke returns its own access token + refresh token pair tied to this user.Profile Sync
Every time a valid external JWT is presented, Replyke compares theuserData fields against the stored user record and updates any fields that have changed. Your user profiles in Replyke stay in sync with your external system automatically — no separate update call needed.
Security
The private key must never leave your server. Signing happens server-side; the client only receives the finished JWT. Because Replyke verifies using your public key, a client cannot forge or modify user data. See SDK Reference → Authentication → External for implementation guidance.OAuth
OAuth allows users to sign in using a third-party provider. Replyke handles the full flow: PKCE generation, state management, callback processing, and user creation or linking. Supported providers: Google, GitHub, Apple, FacebookSetup
Each provider must be configured in the project dashboard with:- The provider’s client ID and client secret
- A list of allowed redirect URIs (the URLs Replyke may redirect back to after authentication)
Flow Overview
Request an authorization URL
Call the authorize endpoint with the provider name and the
redirectAfterAuth URL. Replyke creates a short-lived state record (10-minute TTL) and returns an authorization URL pointing to the provider. For Google, a PKCE code verifier and challenge are generated automatically.Redirect the user to the provider
Redirect the user to the authorization URL. They authenticate with the provider and are sent back to Replyke’s callback endpoint.
Replyke processes the callback
Replyke exchanges the authorization code for the provider’s tokens, fetches the user profile, and resolves which Replyke user to return using this priority:
- Existing identity — if this provider account has signed in before, the matching user is returned immediately.
- Verified email match — if the provider supplies a verified email that matches an existing user, the new identity is linked to that account automatically.
- New user — if no match is found, a new user is created from the provider profile (name, email, avatar).
redirectAfterAuth URL with Replyke tokens appended as query parameters.Account Linking
A user can link multiple OAuth providers (and a password account) to a single Replyke user record. To link an additional provider, the user must be signed in, and the OAuth flow is initiated via the link endpoint rather than the authorize endpoint. The new identity is attached to the existing account. This enables scenarios like “sign in with Google on a laptop and GitHub on another device” — both map to the same user. See SDK Reference → Authentication → OAuth for the full integration guide.Multi-Account Support
The SDK supports multiple simultaneously signed-in accounts in a single app instance. This is separate from account linking — it means multiple distinct user sessions can be held at once, with the ability to switch between them. Use cases: apps where a person manages multiple accounts, shared devices, or testing flows. See SDK Reference → Authentication → Multi-Account for the full guide.Authorization
Beyond authentication, Replyke enforces authorization on every request:- Most write operations require an authenticated user (or a service API key)
- Ownership checks are enforced server-side — a user cannot modify another user’s content through the normal API
- Space roles (owner, admin, moderator, member) control what is permitted within a space
- Service API keys bypass user-level authorization and are intended for server-side use only — see Integration Options