OAuth 2.0 흐름과 토큰 유형

OAuth 2.0은 네 가지 역할을 정의합니다. 리소스 소유자는 데이터(예: 자신의 Google Drive 파일)를 소유한 사용자입니다. 클라이언트는 액세스를 요청하는 애플리케이션입니다. 인가 서버는 액세스 토큰을 발급합니다(예: Google의 OAuth 서버). 리소스 서버는 보호된 데이터를 호스팅합니다(예: Google Drive API). 이러한 역할을 이해하면 각 흐름의 목적을 명확히 파악할 수 있습니다.

인가 코드 흐름은 서버 측 웹 애플리케이션에 적합한 올바른 흐름입니다. 사용자는 인가 서버에서 인증하고, 인가 서버는 수명이 짧은 인가 코드와 함께 클라이언트로 리디렉션합니다. 클라이언트의 서버는 백채널 요청을 통해 이 코드를 토큰으로 교환합니다. 토큰은 브라우저를 거치지 않으므로 브라우저 기록과 리퍼러 유출로부터 보호됩니다.

암시적 흐름은 클라이언트 비밀 값을 안전하게 저장할 수 없는 브라우저 전용 JavaScript 애플리케이션을 위해 설계되었습니다. 토큰이 URL 프래그먼트로 직접 반환되어 백채널을 거치지 않았습니다. PKCE(RFC 7636)를 사용하면 공개 클라이언트가 클라이언트 비밀 값 없이도 인가 코드 흐름을 안전하게 사용할 수 있으므로, OAuth 2.1에서는 암시적 흐름이 폐기되었습니다.

ROPC 흐름을 사용하면 클라이언트가 사용자의 사용자 이름과 암호를 직접 수집하여 토큰으로 교환할 수 있습니다. 이 방식은 신뢰도가 매우 높은 자사 클라이언트를 위해 만들어졌지만, 앱이 사용자의 자격 증명을 보지 못하게 한다는 OAuth의 목적을 근본적으로 무너뜨립니다. OAuth 2.1에서는 폐기되었으며 새로운 애플리케이션에서는 사용해서는 안 됩니다.

클라이언트 자격 증명 흐름은 사용자가 관여하지 않는 기계 간(M2M) 인증을 위한 것입니다. 클라이언트는 클라이언트 ID와 비밀 값을 사용하여 인가 서버에 직접 인증하고, 자체 사용을 위한 액세스 토큰을 받습니다. 일반적인 사용 사례로는 백그라운드 작업, 마이크로서비스 간 통신, 백엔드 서비스에 액세스하는 API 게이트웨이가 있습니다.

장치 인가 흐름(RFC 8628)을 사용하면 스마트 TV, 게임 콘솔, 프린터, IoT 장치처럼 입력 기능이 제한된 장치에서 OAuth를 사용할 수 있습니다. 장치는 짧은 코드와 URL을 표시합니다. 사용자는 휴대폰이나 컴퓨터에서 URL을 방문하여 인가합니다. 장치는 사용자가 인가를 완료할 때까지 인가 서버를 폴링합니다.

OAuth 2.0은 두 가지 액세스 토큰 유형을 정의합니다. 불투명 토큰은 리소스 서버가 인가 서버의 토큰 검사 엔드포인트를 호출하여 유효성을 확인하는 무작위 문자열입니다. JWT 액세스 토큰은 자체 완결형이므로 리소스 서버가 서명을 검증하여 로컬에서 유효성을 확인할 수 있습니다. 이렇게 하면 검사 API 호출은 줄어들지만 키 관리가 필요합니다.

갱신 토큰은 액세스 토큰이 만료된 후 새 액세스 토큰을 받는 데 사용하는 장기 유효 자격 증명입니다. 갱신 토큰 순환(OAuth 2.1에서 공개 클라이언트에 요구됨)을 적용하면 사용할 때마다 새 갱신 토큰이 발급되고 이전 토큰은 무효화됩니다. 탈취된 갱신 토큰이 사용되면 정상 클라이언트가 무효화를 감지할 수 있으므로 토큰 탈취를 탐지할 수 있습니다.

RFC 7662는 토큰 검사 엔드포인트를 정의합니다. 이 엔드포인트를 사용하면 리소스 서버가 불투명 액세스 토큰의 현재 상태(활성/비활성), 범위, 주체, 만료 정보를 인가 서버에 질의할 수 있습니다. 검사를 사용하면 토큰을 실시간으로 폐기할 수 있습니다. 인가 서버에서 토큰이 폐기되면 검사 호출은 즉시 active: false를 반환합니다.

RFC 7009는 토큰 폐기 엔드포인트를 정의하며, 클라이언트가 토큰(액세스 토큰 또는 갱신 토큰)을 무효화해야 한다고 인가 서버에 알릴 수 있게 합니다. 로그아웃할 때나 클라이언트가 의심스러운 활동을 감지했을 때 사용합니다. JWT 액세스 토큰은 폐기 목록 없이는 완전히 폐기할 수 없습니다. 리소스 서버가 인가 서버에 연결하지 않고 로컬에서 유효성을 확인하기 때문입니다.

OAuth 2.0의 범위는 클라이언트가 요청하는 구체적인 권한을 정의합니다. 인가 서버는 사용자가 승인할 수 있도록 요청된 범위를 보여 줍니다. 리소스 서버는 엔드포인트별 범위 요구 사항을 적용합니다. 최소 권한 원칙을 적용해야 하므로 클라이언트는 필요한 최소 범위만 요청하고, 리소스 서버는 범위가 부족한 요청을 거부해야 합니다.

인가 코드 흐름은 서버 측 앱에 적합합니다. 암시적 흐름은 폐기되었으므로 대신 PKCE를 사용해야 합니다. ROPC 흐름은 OAuth의 목적을 없애므로 폐기되었습니다. 클라이언트 자격 증명 흐름은 M2M을 처리합니다. 장치 인가는 입력이 제한된 장치를 지원합니다. 액세스 토큰은 불투명 토큰이거나 JWT일 수 있습니다. 갱신 토큰은 순환해야 합니다. 검사(RFC 7662)와 폐기(RFC 7009)를 함께 사용하면 토큰 관리가 완성됩니다.