OAuth 2.0

OAuth 2.0은 사용자가 자신의 비밀번호를 제3자 애플리케이션에 넘기지 않고도, 자신이 가진 자원에 대한 접근 권한을 그 애플리케이션에 위임(Delegation)할 수 있게 하는 인가(Authorization) 표준 프로토콜이다. 예를 들어 일정 관리 앱이 구글 캘린더를 읽어야 할 때, 사용자는 구글에 직접 로그인해 동의만 하고 앱은 구글이 발급한 액세스 토큰(Access Token)으로 캘린더 API에 접근한다. OAuth의 본질은 로그인 기능이 아니라 권한 위임이며, 이 구분이 면접에서 가장 자주 검증되는 지점이다.

네 가지 역할

OAuth 2.0은 참여자를 네 역할로 나눈다. 자원 소유자(Resource Owner)는 데이터의 주인인 사용자다. 클라이언트(Client)는 사용자의 자원에 접근하려는 제3자 애플리케이션이다. 인가 서버(Authorization Server)는 사용자를 인증하고 동의를 받아 토큰을 발급하는 서버로, 구글 계정 서버가 그 예다. 자원 서버(Resource Server)는 보호된 데이터를 실제로 제공하는 API 서버로, 구글 캘린더 API가 해당한다. 클라이언트는 사전에 인가 서버에 등록해 클라이언트 아이디(Client ID)와 클라이언트 시크릿(Client Secret)을 받아 두며, 토큰이 허용하는 접근 범위는 스코프(Scope)로 명시된다. 스코프 덕분에 사용자는 캘린더 읽기만 허용하고 수정은 막는 식의 세밀한 위임이 가능하다.

인가 코드 그랜트의 흐름

여러 흐름(Grant) 중 표준으로 권장되는 것은 인가 코드 그랜트(Authorization Code Grant)다. 단계는 다음과 같다.

1. 사용자가 클라이언트 앱에서 구글로 연동하기를 누르면, 앱은 클라이언트 아이디, 스코프, 리다이렉트 URI(Redirect URI), 위조 방지용 state 값을 붙여 인가 서버의 동의 화면으로 사용자를 보낸다.
2. 사용자는 인가 서버에서 직접 로그인하고 요청된 권한 범위에 동의한다. 비밀번호는 인가 서버에만 입력된다.
3. 인가 서버가 사용자를 등록된 리다이렉트 URI로 돌려보내며, 짧은 수명의 일회용 인가 코드(Authorization Code)를 쿼리로 전달한다.
4. 클라이언트의 백엔드가 이 코드와 클라이언트 시크릿을 인가 서버의 토큰 엔드포인트에 제출해 액세스 토큰으로 교환한다. 이 통신은 브라우저를 거치지 않는 서버 간 통신이다.
5. 클라이언트는 액세스 토큰을 Authorization 헤더에 담아 자원 서버 API를 호출하고, 자원 서버는 토큰의 유효성과 스코프를 확인한 뒤 데이터를 내준다.

GET /calendar/v3/events HTTP/1.1
Host: api.example.com
Authorization: Bearer ya29.a0AfH6...

코드 교환 단계를 굳이 두는 이유는 토큰이 브라우저 주소창과 히스토리에 노출되는 것을 막고, 시크릿을 아는 진짜 클라이언트만 토큰을 얻게 하기 위해서다. 액세스 토큰이 만료되면 함께 발급된 리프레시 토큰(Refresh Token)으로 사용자 개입 없이 새 토큰을 받아 온다.