OAuth (OAuth 2.0)

OAuth(OAuth 2.0)는 애플리케이션이 다른 서비스의 자원에 제한된 권한으로 접근하도록 하는 권한 위임 체계입니다. 사용자는 외부 앱에 계정 비밀번호를 넘기는 대신, 정해진 범위의 접근을 허용할 수 있습니다. 앱은 발급받은 액세스 토큰으로 자원을 요청하며, 접근 범위와 유효기간 등의 조건에 따라 권한을 행사합니다.

자원 접근을 나누는 네 역할

OAuth 2.0 기본 규격 RFC 6749는 자원 소유자, 클라이언트, 인가 서버, 자원 서버라는 네 역할을 정의합니다. 자원 소유자는 접근을 허용할 수 있는 주체이며, 클라이언트는 허용받은 권한으로 자원을 요청하는 앱입니다. 인가 서버는 승인된 접근에 사용할 액세스 토큰을 발급하고, 자원 서버는 그 토큰을 확인해 보호된 자원 요청을 처리합니다. 역할이 다르다고 반드시 물리적인 서버도 따로 있어야 하는 것은 아닙니다.

사진 보관 서비스의 사진을 인쇄 앱에 맡기면, 사진 이용자가 자원 소유자이고 인쇄 앱이 클라이언트가 됩니다. 사용자가 사진 서비스가 신뢰하는 서버에서 접근을 승인하면 인쇄 앱은 사진을 가져올 권한을 받습니다. 이때 앱에 사진 계정의 비밀번호를 주는 대신 위임된 접근에 쓸 토큰을 제공하는 방식입니다. RFC 6749도 사진 인쇄 예시로 계정 자격 증명과 앱에 부여하는 접근 권한을 구분합니다.

접근 범위를 나타내는 스코프(scope)는 앱이 요청하고 서버가 허용하는 권한을 표현합니다. 사진 읽기와 사진 삭제를 별도 범위로 제공하는 서비스라면, 읽기 권한을 받았다는 사실만으로 삭제까지 허용되지는 않습니다. 다만 실제 스코프 이름과 그 의미는 서비스가 정합니다. 액세스 토큰이 부여하는 범위와 유효기간을 확인해야 어떤 작업을 언제까지 할 수 있는지 판단할 수 있습니다.

권한 위임과 로그인 신원의 차이

OAuth의 자원 접근 허용과 사용자의 로그인 신원 확인은 구분됩니다. ‘이 앱이 사진을 읽을 수 있다’는 정보와 ‘이용자가 누구인지 확인했다’는 정보는 서로 다른 질문에 답합니다. 로그인 화면에 계정을 고르는 단계가 함께 보여도, 앱이 어떤 정보를 받고 무엇을 검증하는지에 따라 기능이 달라집니다. OAuth라는 이름만으로 로그인 처리에 필요한 신원 정보까지 정의됐다고 볼 수는 없습니다.

OpenID Connect Core 규격은 OAuth 2.0 위에 신원 확인 기능을 추가한 계층으로 OpenID Connect를 설명합니다. 이 규격은 인가 서버가 수행한 인증을 바탕으로 앱이 이용자의 신원을 확인하고 기본 프로필 정보를 얻는 방법을 정합니다. 로그인 결과를 전달하는 ID 토큰과 API 접근에 사용하는 액세스 토큰은 용도가 다릅니다. 앱은 받은 값이 어느 목적의 토큰인지에 맞춰 처리합니다.

다른 서비스 계정으로 가입하거나 로그인하는 화면을 구현할 때는 OpenID Connect 지원 여부와 제공되는 신원 정보를 확인합니다. 반면 이미 로그인한 앱이 외부 저장소의 파일을 가져오는 기능은 자원 접근 권한이 중심입니다. 한 서비스 안에서 로그인과 외부 자원 접근이 함께 필요할 수도 있습니다. 사용자에게 비슷한 승인 화면이 보인다는 이유로 두 기능의 처리와 검증을 같은 것으로 취급하지 않습니다.

코드 교환과 토큰 보호의 조건

OAuth 2.0 보안 권고 RFC 9700은 인가 코드의 도용과 주입 공격을 막는 조치를 규정합니다. 클라이언트 자격 증명을 안전하게 보관하기 어려운 공개 클라이언트에는 PKCE 사용을 요구하고, 이를 보관할 수 있는 비공개 클라이언트에도 사용을 권고합니다. PKCE는 코드 교환을 원래 요청과 연결해 보호하는 장치입니다. 액세스 토큰을 받기까지의 절차를 구현할 때 클라이언트의 성격과 지원 조건을 함께 살핍니다.

과거 기본 규격에 실린 흐름이 모두 같은 수준으로 권장되는 것은 아닙니다. 같은 보안 권고는 사용자 비밀번호를 클라이언트에 전달하는 비밀번호 자격 증명 방식의 사용을 금지합니다. 승인 응답에서 액세스 토큰을 바로 돌려주는 implicit 방식도 토큰 유출과 주입 위험을 완화하는 예외 조건을 제외하면 사용하지 않도록 권고합니다. 인가 코드를 받아 토큰 응답으로 교환하는 흐름을 우선하는 이유에는 이런 노출 경로의 차이가 있습니다.

토큰을 받은 뒤에도 권한 확인은 이어집니다. RFC 9700은 액세스 토큰의 권한을 필요한 최소 범위로 줄이고, 그 토큰이 어느 자원 서버와 작업에 쓰이도록 발급됐는지 확인하도록 설명합니다. 토큰이 존재한다는 사실만으로 요청한 작업이 허용되지는 않습니다. 앱에 파일 읽기만 필요하다면 쓰기나 삭제 권한까지 함께 요구하는지 살피고, 서버는 자신에게 발급된 권한과 실제 요청이 맞는지 검사합니다.