In short
OAuth is the standard that lets a user log into your app using an existing account, like Google or GitHub, without ever sharing their password with you. When you click "Continue with Google", OAuth is what happens behind the scenes: Google confirms who the user is and tells your app, so you never see or store their password. It is both more convenient for users and safer for you, because you hold fewer secrets.
How the flow works
You send the user to the provider (say Google) to sign in. They approve sharing some basic information with your app. The provider then sends the user back to your app along with proof of who they are. Your app trusts that proof instead of managing a password itself.
Why it is safer
Storing passwords correctly is genuinely hard and dangerous to get wrong. OAuth means you never store passwords at all, so a whole category of security risk disappears. The provider handles the difficult parts, including things like two-factor authentication, on your behalf.
You usually do not build it yourself
OAuth has many small, security-sensitive details, so almost nobody implements it by hand. Instead you use an authentication service like Clerk that wraps it in a few components. You enable "Login with Google", and the service handles the flow, leaving you to focus on your actual product.
Common beginner confusions
People often blur three related words. Authentication is proving who you are (logging in), authorisation is what you are allowed to do once in, and OAuth is the standard that lets a provider handle the proving part for you. A second confusion is thinking OAuth means you cannot also offer email-and-password login; you can, and most apps offer both side by side. A third is the dev-to-production gap: social login usually works with test credentials while you build, then needs a careful swap to real provider settings before launch. Because an auth service manages all of this, your job is mostly configuration, not cryptography, which is exactly why it is the recommended path.