OAuth 2.0(RFC 6749)은 사용자가 자신의 비밀번호를 제3자 앱에 넘기지 않고도, 특정 리소스에 대한 제한된 접근 권한을 위임(delegate)하게 해 주는 인가(authorization) 프레임워크입니다. '구글 계정으로 캘린더 읽기 권한만 이 앱에 허용' 같은 시나리오가 대표적입니다.
Authorization: Bearer <access_token> (obtained via an authorization flow)핵심 등장인물은 리소스 소유자(사용자), 클라이언트(제3자 앱), 인가 서버(토큰 발급), 리소스 서버(API)입니다. 오늘날 권장 흐름은 Authorization Code Grant + PKCE입니다. ① 앱이 사용자를 인가 서버의 `/authorize`로 보내 로그인·동의를 받고, ② 인가 서버가 redirect_uri로 일회성 authorization code를 돌려주며, ③ 앱이 그 code를 `/token`에서 access token으로 교환하고, ④ 이후 그 토큰을 `Authorization: Bearer`로 API에 제시합니다.
PKCE(Proof Key for Code Exchange)는 code_verifier를 앱이 만들고 그 해시(code_challenge)를 ①에서 먼저 보낸 뒤, ③에서 원본 verifier를 제출하게 해 authorization code가 탈취돼도 교환하지 못하게 막습니다. 원래 모바일·SPA용이었지만 지금은 모든 클라이언트에 권장됩니다. 반면 구식 Implicit Grant와 Password Grant는 폐기(deprecated) 대상입니다.
가장 중요한 개념 구분: OAuth 2.0은 '인가(무엇을 할 수 있는가)'이지 '인증(당신이 누구인가)'이 아닙니다. access token은 '이 토큰으로 이 API를 호출할 권한이 있다'만 보증할 뿐, 사용자의 신원을 표준적으로 알려주지 않습니다. 신원이 필요하면 OAuth 위에 얹은 OpenID Connect를 써야 합니다.
Authorization: Bearer ya29.a0AfH6SMBx3k...access-token...GET /authorize?response_type=code&client_id=abc123
&redirect_uri=https://app.example.com/callback
&scope=openid%20profile%20email
&state=xyz&code_challenge=E9Me...&code_challenge_method=S256 HTTP/1.1
Host: auth.example.comcurl -X POST https://auth.example.com/token \
-d grant_type=authorization_code \
-d code=SplxlOBeZ... \
-d redirect_uri=https://app.example.com/callback \
-d client_id=abc123 \
-d code_verifier=dBjftJeZ4CVP...fetch('https://api.example.com/me', {
headers: { Authorization: 'Bearer ' + accessToken }
});