쉬운 설명
옛날엔 외부 앱이 '구글 계정 연동' 같은 기능을 제공하려면 사용자의 구글 비밀번호를 직접 받아 가는 위험한 방식이 흔했습니다. 한 앱이 해킹되면 그 사용자의 구글 계정 전체가 위험해졌습니다. OAuth는 이 흐름을 바꿉니다.
사용자가 구글의 동의 화면에서 직접 '이 앱에 내 캘린더 읽기 권한을 줍니다'라고 승인하면, 구글이 앱에 액세스 토큰을 발급합니다. 앱은 그 토큰으로 허용된 범위만 접근할 수 있고, 비밀번호는 영영 보지 못합니다. 사용자는 언제든 구글에서 그 권한을 회수할 수 있습니다.
흐름은 보통 네 단계입니다. ① 앱이 사용자에게 '구글로 계속하기'를 보여 줌. ② 사용자는 구글 사이트로 이동해 로그인하고 권한에 동의. ③ 구글이 앱에 인증 코드를 돌려주고, 앱이 그것을 토큰으로 교환. ④ 앱은 그 토큰으로 사용자 정보·캘린더·메일 등 정해진 범위(scope)만 호출. 한 번 발급된 토큰은 만료까지 유효하며, 갱신 토큰으로 새 토큰을 받을 수 있습니다.
OAuth에는 여러 버전과 변형이 있습니다. OAuth 1.0은 옛 버전이고, OAuth 2.0이 현재 표준입니다. OAuth 2.0 위에 '신원 확인' 기능을 표준화한 것이 OpenID Connect(OIDC)입니다. '카카오로 로그인'처럼 우리가 흔히 보는 소셜 로그인은 사실 OIDC 위에서 동작합니다. 즉 OAuth는 원래 '권한 위임'을 위한 표준이고, OIDC는 그 위에서 '신원 확인'을 표준화한 것입니다.
구현 시 주의: OAuth는 표준이지만 보안 함정이 많습니다. 리다이렉트 URL 검증, 토큰 저장 위치, CSRF 방어, PKCE(Proof Key for Code Exchange) 적용 같은 디테일을 잘못하면 큰 사고로 이어집니다. 그래서 직접 구현하기보다 Auth0·Clerk·Supabase·NextAuth 같은 라이브러리/서비스를 쓰는 게 거의 항상 안전합니다.
비유로 보면
OAuth는 자동차 발렛파킹 키와 비슷합니다. 운전기사가 차 주인의 진짜 키를 받지 않고, 발렛 키 — 시동만 걸 수 있고 트렁크는 못 여는 — 를 받습니다. 발렛 키를 잃어도 차 주인의 진짜 키와 트렁크 안 물건은 안전합니다. OAuth의 토큰이 그 발렛 키 역할입니다.
어디에서 만나나
소셜 로그인(카카오·구글·애플·페이스북), API 권한 위임(노션 API·구글 캘린더·슬랙·깃허브), SaaS 사이의 통합(예: 영업 도구에서 캘린더 자동 동기화), 모바일 앱의 클라우드 동기화. 거의 모든 현대 서비스가 OAuth 통합을 한두 개는 가지고 있습니다.
작은 예시
스타트업 가계부 앱이 '카카오로 시작' 버튼을 제공합니다. 사용자는 카카오 동의 화면에서 '이메일과 닉네임 제공'에 동의하고, 앱은 그 정보로 회원 가입을 처리합니다. 사용자의 카카오 비밀번호는 앱이 본 적도 알 수도 없습니다.
자주 하는 오해
한 줄 정리
OAuth의 진짜 가치는 '비밀번호를 넘기지 않고 권한을 나눈다'에 있습니다. 사용자는 통제를 유지하고, 앱은 필요한 만큼만 받습니다.