OAuth · Social Login
OAuth
What is OAuth?
- The “Log in with Google or Kakao” standard
- Delegate access without sharing passwords
- Secure social login
Once you add OAuth, the first thing that changes, even before the login screen, is who is responsible for passwords. The password-hash column disappears from the member database, and only the token issued by the provider and a user identifier remain. Even if your server is breached, no one’s password for another service leaks. For two-factor authentication, anomalous-login detection, and device management, you borrow the most labor-intensive security features at the provider’s level. An entire high-maintenance area of the member system comes off your hands.
One boundary often gets blurred in practice: OAuth 2.0 is an authorization protocol, not authentication. Confirming 'who this person is' is the job of the OpenID Connect ID token layered on top, while the access token OAuth issues is a pass stating 'how far this app may go.' Tokens carry a scope and an expiry; access tokens are usually set to about an hour, and refresh tokens to several weeks or months. Flows have diverged too: current web and app recommendations are the authorization code flow plus PKCE, and the implicit flow, which sent tokens straight to the browser, has been dropped.
If you serve the Korean market, weigh provider differences up front. Kakao treats email as an optional consent item, so you can only receive it after converting to a business app and passing review. With Apple login, if the user chooses 'Hide My Email,' a random relay address is passed instead of the real one. Add Google and Naver and the same person can create three or four accounts just by switching channels. Unless you first set a rule of using each provider’s unique identifier, not email, as the primary key, merging members later will cost many times more.
Incidents usually come from two places. First, teams mistake the access token for proof of identity and treat 'a token arrived' as 'login succeeded.' A token issued to another app can be passed in as-is to get into someone else’s account, so skipping verification of the ID token’s issuer and audience (aud) leaves the door wide open. Second, teams bolt on social login and nothing else. If the provider goes down for maintenance or changes its policy, even a 30-minute block locks every member out, and when a user revokes the connection, an account with payment history is left with no owner. The rule is to keep at least one alternative login method. And if the consent screen requests permissions you will never use, you risk rejection in review or a noticeable drop in consent rates.
Seungtae ParkA hands-on AX instructor who teaches AI business development and marketing automation by building them in practice
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, helping non-specialists put AI to work right awayOAuth 1.0 was published in 2007, and OAuth 2.0 was standardized in 2012, becoming the de facto standard for social login and API permission delegation.
Consider a hypothetical case. Company A, an online job-training platform with 140 employees and annual revenue of around KRW 32 (≈ US$1) billion, had managed 280,000 members with its own IDs and passwords. When password-recovery inquiries piled up to 410 a month and sign-up drop-off hit 47%, it launched an eight-week project to switch to social login.
- The head of service planning dug into sign-up logs from the past three months and found that an average of 320 people a day dropped off without opening the verification email. 'Cut 12 input fields down to two clicks' became the project title.
- The dev team integrated Kakao, Google, and Apple using the authorization code flow with PKCE, and trimmed the requested permissions to just two: nickname and email. The date of birth and gender that the marketing team wanted were dropped because of review delays.
- At the review meeting, the assistant security manager said, 'We can’t approve anything based on the access token alone,' and had the team add verification of the ID token’s issuer and audience (aud). The change blocked all 12 simulated token-injection tests.
- We resolved conflicts with the existing 280,000 accounts by using each provider’s unique identifier as the primary key, and by building a separate screen that merges accounts after identity verification when emails overlap. The 1,900 users with Apple relay addresses were handled as a separate exception.
- Eight weeks after the switch, sign-up completion rose from 53% to 78%, and password-related inquiries fell from 410 to 46 a month. Because email login was kept as a backup, payments kept running even during a 40-minute provider outage in March.