Setting Up Social Login
Pick your provider to get a step-by-step guide for registering your app and pasting the Client ID into DontCode.
Pick a provider
Each provider has its own developer console, terminology, and approval flow. Open the guide for the one you want to set up. They are independent, you can do one and skip the other.
Kakao OAuth Setup
Essential for the Korean market. Most Korean users will not sign up without a Kakao login option. Heads up: DontCode requires an email for every user, and Kakao does not let your app collect email until you upgrade to a "Biz App". This guide walks through both — the OAuth credentials, and the Biz App upgrade (free, available even if you are an individual developer with no business registration).
Open the guide →
Google OAuth Setup
Used worldwide. Most users already have a Google account, so this is the highest-converting social login outside Korea.
Open the guide →
What you will do
You will create a developer project on each OAuth provider you want to support, configure a redirect URL, copy the Client ID, and paste it into your DontCode project. Once you redeploy, the social login buttons on your live site start working.
Before you begin
- Your DontCode project must be deployed (or have a target deploy URL ready).
- You need a developer-facing account for each provider you intend to enable.
- You have admin or owner role on your DontCode project.
Your redirect URL
Every provider asks you for a "Redirect URI" or "Callback URL". This is the address the provider sends users back to after they approve sign-in. For DontCode apps, the pattern is the same regardless of provider:
https://<your-deployed-domain>/api/auth/oauth/callbackReplace <your-deployed-domain> with your actual deployed URL. If you are using a custom domain, use that. You can register multiple redirect URLs with each provider, which is handy if you want to keep using both your *.dontcode.cafe subdomain and your custom domain.
How OAuth works (in 30 seconds)
- A user clicks "Sign in with X" on your deployed app.
- Your app redirects them to the provider, including your Client ID.
- The user approves the sign-in on the provider's page.
- The provider redirects them back to your app with a one-time code.
- Your app exchanges that code for the user's identity (email, name, etc.) and creates a session.
Troubleshooting (applies to all providers)
Users see "redirect_uri_mismatch"
The redirect URL registered with the provider does not match the one your deployed app actually uses. Double-check spelling, http vs https, and trailing slashes. Most providers let you register multiple redirect URIs. Add every variant you might use (custom domain + dontcode.cafe subdomain).
Login button does not appear after saving
OAuth client IDs only get pushed to your deployed app on the next deploy. Hit Deploy in the editor. The buttons appear once the new build is live.
Related: how we secure user passwords
OAuth handles sign-in for users who pick a social provider. For users who sign up with email and password, we run their credentials through Argon2id, salt every hash, and isolate each project's auth pool. Worth sending to anyone who asks how your app stores passwords.
Read the security guide →