Sign-in
When your actions work with a user’s own account (their workouts, bookings, orders), each user signs in once with the account they already have. From then on, every action runs as that user, on their account only.
What your users see
- They add your connector in their assistant. The assistant opens a page with your logo and brand colour: “Let Claude use your YourApp account?”, listing what the assistant will be able to do. Actions you set to confirm are marked “asks you first”. They click Allow.
- They sign in on your login page, or just approve if they’re already logged in.
- They’re sent back to the assistant, connected. They stay connected while they keep using it; there’s no need to sign in again each time.
Their password goes to your login (or your auth provider), never to the assistant, and Gephyr never stores it.
How it works with your login
| Your users log in with… | How Gephyr signs them in |
|---|---|
| An auth provider with OAuth / OpenID Connect: Auth0, Okta, Clerk, Amazon Cognito, WorkOS, Microsoft Entra, Google, Keycloak, and others (including Supabase’s OAuth server, if you choose it over direct sign-in) | Users are sent to your provider’s own login page, which keeps your branding, two-step verification, social logins and passkeys |
| Firebase Auth or Supabase Auth | A sign-in page with your branding, hosted by Gephyr. The password goes from the user’s browser straight to Firebase or Supabase. Your API receives the same Firebase/Supabase tokens it already accepts. |
Your own login (no OAuth): your own login endpoint, such as POST /auth/login returning a token |
A sign-in page with your branding, hosted by Gephyr. Gephyr sends the email and password once to your login address and keeps only the token it returns. You show you own that address with a DNS record or a file. See Your own login. |
Setting it up
Open Sign-in in your dashboard and enter your app’s domain. Gephyr detects your provider and shows a tile for it, with the best setup option first:
- Connect (Auth0, Okta, Clerk): paste an admin key once and Gephyr creates everything it needs in your account. The key is used for that setup only and never stored. Connect with Supabase does the same for Supabase, and Connect with Google adds your connector to a Firebase project’s authorized domains for you.
Proving you own your login. Publishing needs a login you control, so nobody can publish a look-alike of your app wired to your real login. With an OAuth provider, the tokens your login issues go to your API, so you show you own your API’s address with a DNS record or a file, and your login’s addresses the same way (one record on your domain covers both) unless you connected Auth0, Okta or Clerk with an admin key, which proves the login is yours. See Show you own your API and your login. For Firebase, Gephyr checks that your app’s own proof address, shown on the Login step, is in your project’s authorized domains (step 2 of the Firebase setup). For Supabase, click Connect with Supabase on the Login step and pick your project. For your own login, add the DNS record or file Gephyr shows for your login address, then test sign-in with your own account.
- Guided steps (all providers): the exact clicks for your provider, with the address to copy.
- Stuck? Get a ready-made prompt for your own AI assistant, send the steps to your developer, or book a setup call.
Every option ends with Test sign-in. Step-by-step instructions for each provider are in Providers.
Once your login is confirmed, choose who can use it: anyone with an account, or only your paying customers (Launch and up).
What Gephyr keeps, and how
- Your users’ passwords: never stored. With your own login, they pass through Gephyr once on the way to your login address; with every other option Gephyr never sees them.
- Your app’s tokens for each user: encrypted with a key unique to your company, and only used to call your API for that user.
- Who the user is: a stable account ID from your provider, checked at sign-in. It’s never an email address.
- Logs: a pseudonymous ID, never names, emails or tokens.
Ending access
- Users disconnect from their assistant at any time, and access stops on the next request.
- You can disconnect a person, or everyone, under Disconnect people on the Protection tab. It takes effect at once, on every link: their AI app stops working with your app until they connect again. Block does the same and also refuses every later sign-in until you unblock them (blocked people are listed there, each with Unblock); they see a Gephyr page saying your app turned off AI access for their account. To find the person, type their user ID in your app (the ID your sign-in uses: their Firebase UID, Supabase user ID, or the user ID your login or OAuth gives Gephyr) and Gephyr works out their anonymous ID; nothing is stored. Or pick them from Most active people on the same card (the last 7 days, with how many of their calls limits stopped), or from the User column on Activity. Neither changes their account in your app.
- If your app revokes a user’s session, Gephyr notices and asks the assistant to reconnect.
Accounts with two-step verification
With an OAuth provider, two-step verification works as normal on your login page. With Firebase or Supabase sign-in, or your own login, accounts that have two-step verification turned on can’t connect yet. They see a clear message, and support is coming.
Something missing or wrong? Email hello@gephyr.ai.