Authentication

Let your app’s users sign in with email/password, Google, or GitHub. Authentication is built on Supabase Auth and configured per project.

Important: this is YOUR app’s authentication

Don’t confuse this with how you sign into Devaiy itself. This page is about giving the end users of the app you’re building a way to sign in. The two are completely separate.

The dependency chain

Auth methods build on each other. You enable them in order:

  1. Supabase must be connected first. Auth lives on Supabase, so there’s nothing to enable without it. See Supabase.
  2. Enable Email/Password next. This is the foundation.
  3. Add Google or GitHub OAuth on top. These can only be enabled AFTER email/password is on.

In the Project Settings → Authentication tab, options that aren’t yet unlocked appear greyed out with a note explaining what needs to happen first.

Step 1 — Email and password

Once Supabase is connected, you have two ways to turn on email/password auth:

  • Ask the AI to enable authentication. The AI turns on the Email & Password provider in Supabase for you and builds the sign-up, sign-in, and forgot-password screens in the same turn. Easiest path.
  • Enable it yourself from the Authentication tab. Click Enable on the Email & Password card to configure the Supabase provider, then tell the AI — e.g. “I’ve enabled email/password auth, please add the sign-up and sign-in screens” — and it’ll wire up the frontend.

Either way, the AI uses the standard Supabase Auth client (supabase.auth.signUp, supabase.auth.signInWithPassword, etc.) and the resulting session is stored in the user’s browser automatically.

Step 2 — Google OAuth

After Email is enabled, the Google card unlocks. You’ll need to provide a Google Client ID and Client Secret — these come from the Google Cloud Console.

Quick setup in Google Cloud Console:

  1. Create a project (or use an existing one).
  2. Configure the OAuth consent screen with: app name, support email, and the single “openid email profile” scope set (avoid any sensitive scopes — those trigger Google’s formal review process).
  3. Create an OAuth client ID of type “Web application”.
  4. Add the Supabase callback URL to authorized redirect URIs. Devaiy shows you the exact URL after you click Configure on the Google card — copy it from there.
  5. Copy the Client ID and Client Secret, paste them into Devaiy’s Configure dialog, click Save.

After saving, head back to the AI chat and let it know — e.g. “I’ve saved my Google Client ID and Secret, please add a Sign in with Google button to the login screen” — so the AI can make the frontend changes. Saving credentials only configures Supabase; the frontend wiring is a separate step.

Step 3 — GitHub OAuth

Same idea, with GitHub as the provider. In GitHub Developer Settings → OAuth Apps → New OAuth App, set:

  • Application name: whatever you want users to see
  • Homepage URL: your app’s deployed URL (or localhost for testing)
  • Authorization callback URL: Devaiy shows you the exact URL when you click Configure on the GitHub card — copy it from there.

Click Generate a new client secret, copy Client ID and Client Secret, paste them into Devaiy, Save.

After saving, head back to the AI chat and let it know — e.g. “I’ve saved my GitHub Client ID and Secret, please add a Sign in with GitHub button to the login screen” — so the AI can make the frontend changes. Saving credentials only configures Supabase; the frontend wiring is a separate step.

Where credentials are stored

Devaiy doesn’t store your Google or GitHub Client Secrets in our database. They go directly into your Supabase Auth configuration. Devaiy connects to your Supabase via OAuth (limited scope) and updates the auth provider settings — Supabase then handles the actual OAuth flow for your end users.

Troubleshooting

  • “redirect_uri_mismatch” error from Google/GitHub. The callback URL in your OAuth app config must exactly match the one Devaiy shows you. Copy-paste from Devaiy’s Configure dialog, don’t retype.