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.
OAuth lets users log in with an existing account like Google without sharing their password with you. Learn how it works and why it is safer.
A .env file stores secrets like API keys outside your code so they never get published. Learn what it is, how it works and how to keep it safe.
An API is a way for two programs to talk to each other. Learn what an API is, how it works, and why it matters for building with AI.
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.
Comments
Loading comments.
Post a comment