--- title: "Clerk: Authentication and OAuth from Dev to Production" description: "Add real authentication with Clerk, wire up Google OAuth, and take it from a dev instance to a production instance on your own domain" type: "lesson" locale: "en" course: "The Modern App Stack - Auth, Data and Payments" number: "3.2" canonical: "https://agenticschool.dev/courses/modern-app-stack/clerk-authentication-and-oauth-from-dev-to-production" datePublished: "2026-06-12" dateModified: "2026-06-12" --- # Clerk: Authentication and OAuth from Dev to Production - Course: The Modern App Stack - Auth, Data and Payments - Lesson: 3.2 - Duration: 30 min - Level: fortgeschritten - Status: published - Canonical URL: https://agenticschool.dev/courses/modern-app-stack/clerk-authentication-and-oauth-from-dev-to-production - Locale: en > Add real authentication with Clerk, wire up Google OAuth, and take it from a dev instance to a production instance on your own domain ## Summary Authentication is one of the easiest things to get dangerously wrong, so you never build it yourself - you use a dedicated service. This lesson explains what OAuth actually is, why hand-rolling auth is a trap, how to add Clerk, and how to move cleanly from a development instance to a production instance, including the full Google OAuth walkthrough: consent screen, credentials and the custom-domain DNS records you add at the end. ## What you learn - What OAuth is conceptually and why you must never hand-roll authentication - Adding Clerk and the difference between a development instance and a production instance - A full Google OAuth production walkthrough: consent screen, credentials and custom-domain DNS records ## Summary Your app now needs users: people who sign up, log in, and have their own data. That is authentication, and it is a place where a small mistake leaks every customer password you hold. The right move in 2026 is unambiguous: do not build it yourself, use a service. Clerk is that service for most of the builders this course is for. This lesson explains the one concept you must understand (OAuth), gets Clerk into your app, and then takes you through the part everyone finds fiddly - going from development keys to a real production instance with Google sign-in on your own domain. ## What you will learn You will learn what OAuth is in plain language, why hand-rolling auth is a trap that even large companies fall into, how Clerk fits your app, the crucial difference between a development instance and a production instance, and the exact steps to enable Google OAuth in production, including the Google consent screen, credentials, and the DNS records that make it run on your domain. ## Prerequisites A working app from Course 1 and the architecture map from the previous lesson, since auth lives on the app side, not the marketing site. You also need the secrets discipline from Course 1: auth keys are highly sensitive and must never be committed. The next lesson on secrets goes deeper, but the basic rule (keys in .env, .env in .gitignore) must already be second nature. ## The problem Building auth yourself sounds like a rite of passage. It is actually a minefield. You have to hash and salt passwords correctly, manage sessions and tokens, handle password resets, defend against credential stuffing and brute force, store everything securely, and keep up with new attack techniques forever. Get one detail wrong and you leak customer data, which is a legal and reputational disaster. Meanwhile your competitors using Clerk shipped login in an afternoon and moved on to building their actual product. There is no prize for the hand-rolled version. This is a solved problem, and your job is to use the solution, not reinvent it. ## What OAuth actually is OAuth is the protocol behind every "Sign in with Google" or "Sign in with GitHub" button. The core idea is delegation without sharing your password. When a user clicks "Sign in with Google", your app never sees their Google password. Instead, your app hands them off to Google, Google confirms who they are and asks them to approve sharing their email and name with your app, and Google sends back a token that proves "yes, this is really them". Your app trusts Google's word. That is the whole concept: a trusted third party vouches for the user so you never have to store or verify their password. It is more secure (you hold no passwords), more convenient (one click, no new account), and it is what users expect. Clerk handles the entire OAuth dance for you - you just enable the providers you want. - OAuth = let a trusted provider (Google, GitHub, Apple) vouch for the user so you never touch their password. - Your app gets a token proving the identity, plus basic profile info the user approved sharing. - More secure for you (no passwords stored), more convenient for them (one click). - Clerk runs the OAuth flow; you enable a provider and add its credentials. ## Adding Clerk to your app Clerk gives you drop-in components for sign-up, sign-in, user profile and session management, plus the backend pieces to protect your routes. You install its package, add your keys to your environment, wrap your app in its provider, and drop in the prebuilt components. The keys come in two flavours: a publishable key (safe in frontend code, it only identifies your app) and a secret key (backend only). The exact import paths depend on your framework, so follow Clerk's docs for the precise lines. ```bash # .env.local - dev keys, never committed (.env* is gitignored) VITE_CLERK_PUBLISHABLE_KEY=pk_test_xxxxxxxxxxxxxxxxxxxx CLERK_SECRET_KEY=sk_test_xxxxxxxxxxxxxxxxxxxx ``` Clerk keys live in your env file. Note the pk_test / sk_test prefixes - those mean development. Notice the test prefixes. A development instance issues keys that start with pk_test and sk_test; a production instance issues pk_live and sk_live. That prefix is your at-a-glance check for which environment a key belongs to, and it is the single most common thing people mix up. Once your keys are set, you wrap your app in Clerk's provider and use its components. ```tsx // A protected page: only signed-in users see the content. import { SignedIn, SignedOut, SignInButton, UserButton } from '@clerk/clerk-react' export function AppShell() { return (
) } ``` Clerk components handle the entire signed-in / signed-out UI for you. ## Development instance versus production instance Clerk separates your project into two completely independent instances. The development instance is for building: it uses test keys, runs on a Clerk-provided shared domain, and ships with relaxed settings so you can iterate fast. It is not meant for real users. The production instance is the real thing: live keys, your own domain, stricter security, and the place real customers sign in. The two do not share users or settings - they are separate worlds. The mistake beginners make is treating the development instance as good enough and pointing real users at it, or shipping with pk_test keys still in their production environment. The clean flow is: build and test everything on the development instance, then create the production instance, configure it (including a custom domain and OAuth), and swap your deployed environment variables over to the pk_live and sk_live keys. - Development instance: pk_test / sk_test keys, shared Clerk domain, relaxed settings, for building only. - Production instance: pk_live / sk_live keys, your own domain, strict settings, for real users. - They are separate worlds - users and config do not carry over automatically. - Going live = create the production instance, configure it, swap the deployed env vars to the live keys. ## Google OAuth production walkthrough On the development instance, Clerk lets you enable Google sign-in with shared dev credentials so you can test instantly. For production, Google requires that you use your own Google credentials and a verified consent screen, so your users see your app name (not Clerk's) when they sign in. This is the part that trips people up, so here is the order that works. The exact button labels in the Google Cloud Console shift over time, so trust the flow and follow Clerk's and Google's current docs for the precise clicks. - In the Google Cloud Console, create (or pick) a project for your app. - Configure the OAuth consent screen: set the app name, support email, and your domain. Add the scopes for email and profile. Publish it so it is not stuck in test mode. - Create OAuth credentials of type "OAuth client ID" for a web application. Google gives you a Client ID and a Client Secret. - Add the authorized redirect URI that Clerk shows you in its Google provider settings - this is where Google sends the user back after they approve. - Paste the Google Client ID and Client Secret into Clerk's Google provider settings on your production instance, and enable it. - Test: sign in with Google on your production domain. Users should see your app name on the Google consent screen, not a generic one. A subtle gotcha: the redirect URI must match exactly, including https and no trailing slash differences. If sign-in fails with a redirect_uri_mismatch error, that exact-match check is almost always the cause. Copy the URI from Clerk verbatim. ## Custom domain and DNS records A production Clerk instance runs on your own domain so that auth happens at, for example, accounts.yoursite.com or clerk.yoursite.com instead of a generic Clerk URL. To make that work you add DNS records that Clerk gives you to your domain provider (or Cloudflare, from Course 1). These are usually CNAME records that point a subdomain at Clerk's servers so Clerk can serve and secure that subdomain. You add them, wait for DNS to propagate, and Clerk verifies them and issues the certificates. Here is the shape of what you add - your real values come from the Clerk dashboard. ```text ; DNS records you add at your provider (example shape - copy real values from Clerk) ; Type Name (host) Value (target) CNAME clerk frontend-api.clerk.services CNAME accounts accounts.clerk.services CNAME clkmail mail.xxxxx.clerk.services CNAME clk._domainkey dkim1.xxxxx.clerk.services CNAME clk2._domainkey dkim2.xxxxx.clerk.services ``` Production Clerk uses CNAME records on subdomains. The mail/domainkey ones let Clerk send verification emails from your domain. If you manage DNS through Cloudflare, add these as DNS-only (grey cloud, not proxied) unless Clerk says otherwise - proxying auth subdomains can break the TLS handshake. After you save the records, verification can take anywhere from a few minutes to a couple of hours. It is not broken, DNS is just slow, exactly as you learned when connecting a domain in Course 1. ## Typical mistakes The classics: shipping to production with pk_test keys still set, so real users hit your development instance; forgetting to publish the Google consent screen, leaving it in test mode where only whitelisted accounts can sign in; a redirect_uri_mismatch from a redirect URI that is off by a slash or http versus https; proxying the Clerk DNS records through Cloudflare and breaking certificates; and the deepest one of all, trying to build auth from scratch "to learn" and shipping a security hole. Use the service, check your key prefixes, copy redirect URIs verbatim. ## Business ROI Auth is pure downside risk if you build it and pure leverage if you buy it. A leaked password table is a legal nightmare under GDPR and the US privacy laws, plus a trust catastrophe that can end a young product. Clerk removes that entire risk category for a modest monthly cost, and gives you social login, which measurably lifts sign-up conversion because users hate creating yet another password. You ship login in an afternoon instead of a fortnight, you sleep at night, and your sign-up funnel converts better. There is no version of the maths where hand-rolling auth wins for a founder building with agents. ## Checklist You are ready to move on when all of these are true on a real app, not just in theory. - You can explain OAuth in one sentence: a trusted provider vouches for the user so you never hold their password. - Clerk is installed, keys are in .env (gitignored), and signed-in / signed-out UI works. - You know the difference between pk_test and pk_live and which environment each belongs to. - Google OAuth works on your production domain with your own consent screen and the right DNS records. ## Resources Keep the Clerk docs and the Google Cloud Console OAuth guide open while you do the production setup - both change their exact UI over time, and the docs are always current. The Fundamentals pages on what OAuth is and what DNS is back up the two trickiest concepts here. Next, you give your logged-in users something to do: real data with Convex. ## Your task Add Clerk to a test app on the development instance and get sign-in working, then enable Google sign-in. If you own a domain, go one step further: create a production instance, set up the Google consent screen and credentials, add the DNS records, and confirm a real Google sign-in works on your domain with your app name on the consent screen. Doing the production path once removes the fear for every app you build after this. ## Next lesson Users can log in. The next lesson gives them data with Convex, a reactive, type-safe database where your backend logic and your UI stay in sync automatically, and where you will also learn the soft-delete pattern that lets you recover a user mistake instead of losing data forever. ## Transcript This lesson is a written, text-first guide. Authentication is one of the easiest things to get dangerously wrong, so you never build it yourself - you use a dedicated service. This lesson explains what OAuth actually is, why hand-rolling auth is a trap, how to add Clerk, and how to move cleanly from a development instance to a production instance, including the full Google OAuth walkthrough: consent screen, credentials and the custom-domain DNS records you add at the end. You will add real authentication with clerk, wire up google oauth, and take it from a dev instance to a production instance on your own domain. Work through the sections in order, try the task at the end in a real project, and move on once it works for you. There is no video required - everything you need is in the written steps above.