OAuth (r1)

OAuth 프레임워크는 네 가지 주요 역할을 정의하여 인증 및 권한 부여 흐름에서 각자의 책임을 명확히 구분한다.

첫 번째 역할은 리소스 오너(Resource Owner)이다. 이는 보호된 자원(예: 사용자의 계정 정보, 사진, 연락처 등)에 대한 접근 권한을 부여할 수 있는 주체를 의미한다. 일반적으로 최종 사용자인 사용자(End-User)가 이 역할을 수행한다. 리소스 오너는 클라이언트 애플리케이션이 자신의 자원에 접근하는 것을 허용하거나 거부할 최종 결정권을 가진다.

나머지 세 역할은 서비스 제공 측면에 속한다. 클라이언트(Client)는 리소스 오너를 대신하여 보호된 자원에 접근을 요청하는 애플리케이션이다. 웹 애플리케이션, 모바일 앱, 데스크톱 애플리케이션 등이 여기에 해당한다. 인증 서버(Authorization Server)는 리소스 오너의 인증을 확인하고, 클라이언트에게 접근 권한을 나타내는 액세스 토큰을 발급하는 서버이다. 마지막으로 리소스 서버(Resource Server)는 보호된 자원을 호스팅하고, 유효한 액세스 토큰을 제시하는 요청을 수락하여 해당 자원을 제공하는 서버이다.

인증 서버와 리소스 서버는 물리적으로 같은 서버에 위치할 수도 있고, 확장성과 보안을 위해 분리되어 구성될 수도 있다. 이 네 가지 역할의 상호작용을 통해 리소스 오너의 비밀번호를 클라이언트에게 직접 노출시키지 않으면서도 안전하게 위임된 접근 권한을 부여하는 위임 접근(Delegated Access)이 가능해진다.

OAuth 2.0 프레임워크의 핵심은 액세스 토큰과 리프레시 토큰이라는 두 가지 주요 토큰을 사용하여 리소스 서버에 대한 접근을 위임하고 관리하는 것이다.

액세스 토큰은 클라이언트가 보호된 리소스에 접근할 수 있도록 허용하는 자격 증명이다. 이 토큰은 일반적으로 JWT 형식이나 불투명한 문자열로 발급되며, 리소스 서버에 제출되어 요청의 인가를 증명한다. 액세스 토큰에는 권한 범위(스코프), 유효 기간, 클라이언트 식별자 등의 정보가 포함될 수 있다. 보안상의 이유로 액세스 토큰의 수명은 비교적 짧게 설정되는 것이 일반적이다[2].

리프레시 토큰은 액세스 토큰이 만료되었을 때 새로운 액세스 토큰을 얻는 데 사용되는 자격 증명이다. 사용자가 매번 재인증하지 않고도 지속적인 접근을 가능하게 한다. 리프레시 토큰은 액세스 토큰보다 훨씬 긴 수명을 가지며, 클라이언트에 안전하게 저장되어야 한다. 이 토큰이 탈취되면 공격자가 장기간 새로운 액세스 토큰을 발급받을 수 있으므로, 인가 서버는 리프레시 토큰의 사용을 모니터링하고 취소할 수 있는 메커니즘을 제공한다.

권한 부여는 클라이언트 애플리케이션이 사용자의 리소스에 접근할 수 있는 권한을 얻기 위해 사용하는 자격 증명 또는 메커니즘을 의미한다. OAuth 2.0 프레임워크에서 클라이언트는 이 권한 부여를 획득하여 액세스 토큰을 교환한다. 권한 부여의 구체적인 형태는 클라이언트의 유형과 요구사항에 따라 달라지며, 이를 권한 부여 유형이라고 부른다.

주요 권한 부여 유형은 다음과 같다.

권한 부여 과정의 핵심은 리소스 오너가 클라이언트에게 자신의 리소스에 대한 제한된 접근 권한을 위임하는 것이다. 클라이언트는 선택한 권한 부여 유형에 따라 정의된 프로토콜을 정확히 따라야 하며, 획득한 권한 부여(예: 인가 코드)는 반드시 사전에 등록된 리디렉션 URI로만 전송되어야 한다. 이는 보안을 유지하는 중요한 요소이다.

Authorization Code Grant는 OAuth 2.0에서 가장 일반적이고 안전하게 사용되는 권한 부여 유형이다. 이 방식은 클라이언트가 사용자 에이전트(일반적으로 웹 브라우저)를 통해 인증 서버로 리디렉션하여 사용자 인증을 수행한 후, 권한 부여 코드를 받아 다시 액세스 토큰으로 교환하는 두 단계의 흐름을 가진다. 이는 클라이언트가 사용자의 자격 증명을 직접 처리하지 않으며, 액세스 토큰이 사용자 에이전트를 거치지 않고 백채널로 전달되기 때문에 보안성이 높다.

전형적인 흐름은 다음과 같은 단계로 이루어진다.

1. 클라이언트는 사용자를 인증 서버의 권한 부여 엔드포인트로 리디렉션한다. 이때 요청에는 response_type=code, 클라이언트 식별자, 리디렉션 URI, 요청된 권한 범위(Scope) 등이 포함된다.

2. 사용자는 인증 서버에서 인증을 완료하고 클라이언트에게 권한을 부여한다.

3. 인증 서버는 사용자 에이전트를 사전에 등록된 리디렉션 URI로 돌려보내며, 요청 파라미터에 권한 부여 코드를 첨부한다.

4. 클라이언트는 이 권한 부여 코드를 사용하여 인증 서버의 토큰 엔드포인트에 직접 요청을 보낸다. 이 요청에는 코드, 리디렉션 URI, 클라이언트 자격 증명(클라이언트 비밀 등)이 포함된다.

5. 인증 서버는 코드를 검증한 후, 액세스 토큰(및 선택적으로 리프레시 토큰)을 클라이언트에게 직접 응답한다.

이 유형은 클라이언트 비밀을 안전하게 저장하고 유지할 수 있는 웹 애플리케이션 서버나 모바일 앱과 같은 기밀 클라이언트에 적합하다. 권한 부여 코드 자체는 액세스 토큰이 아니므로, 중간에 탈취되더라도 클라이언트 자격 증명 없이는 토큰으로 교환할 수 없다는 점이 핵심 보안 장점이다. 또한, Proof Key for Code Exchange 확장을 함께 사용하면 공개 클라이언트(예: 단일 페이지 애플리케이션, 네이티브 앱)에서도 코드 교환 과정을 보호할 수 있어 현대적인 보안 표준으로 권장된다.

Implicit Grant는 OAuth 2.0의 권한 부여 유형 중 하나로, 주로 클라이언트가 공개된 환경(예: 자바스크립트 기반 싱글 페이지 애플리케이션)에서 실행될 때 사용된다. 이 유형은 Authorization Code Grant와 달리 중간 단계인 '인가 코드' 교환 없이, 인증 서버가 직접 클라이언트에게 액세스 토큰을 발급한다는 특징이 있다.

인증 흐름은 다음과 같다. 먼저, 클라이언트는 리소스 오너를 인증 서버의 인증 페이지로 리디렉션한다. 리소스 오너가 로그인하고 권한을 승인하면, 인증 서버는 액세스 토큰을 URL의 프래그먼트(#) 부분에 담아 클라이언트로 리디렉션한다. 클라이언트는 자바스크립트 등을 통해 이 토큰을 추출하여 리소스 서버에 접근하는 데 사용한다. 리프레시 토큰은 이 흐름에서 발급되지 않는다.

이 방식은 구조가 단순하고 추가적인 백엔드 호출이 필요 없다는 장점이 있지만, 액세스 토큰이 브라우저에 직접 노출되어 토큰 탈취 등의 보안 위험에 더 취약하다. 이러한 보안 문제로 인해, 최신 보안 권고에서는 공개 클라이언트에도 Authorization Code Grant와 PKCE 확장을 함께 사용하는 것을 더 권장한다[4].

Resource Owner Password Credentials Grant는 사용자가 자신의 자격 증명(사용자명과 비밀번호)을 직접 클라이언트 애플리케이션에 제공하여 액세스 토큰을 얻는 권한 부여 유형이다. 이 방식은 주로 클라이언트 애플리케이션을 사용자 측에서 높은 신뢰를 할 수 있을 때, 예를 들어 같은 조직에서 개발한 공식 애플리케이션이나 기기의 운영 체제 자체 애플리케이션 등에서 사용된다. 사용자가 자신의 비밀번호를 직접 입력해야 하므로, 일반적인 권한 부여 코드 부여(Authorization Code Grant) 방식보다 보안 위험이 높은 것으로 간주된다.

이 흐름은 OAuth의 다른 유형들과 달리, 사용자의 동의를 묻는 별도의 인증 서버 리디렉션 단계를 생략한다. 대신 클라이언트는 사용자로부터 받은 자격 증명을 직접 인증 서버의 토큰 엔드포인트로 전송한다. 인증 서버는 이를 검증한 후, 액세스 토큰(및 선택적으로 리프레시 토큰)을 클라이언트에게 직접 발급한다. 이 과정은 일반적으로 단일 HTTP 요청-응답으로 완료된다.

이 방식을 사용하는 경우는 매우 제한적이며, 다음과 같은 조건이 권장된다.

• 클라이언트 애플리케이션이 사용자에게 완전히 신뢰받는 경우(예: 서비스 제공자가 공식적으로 배포한 애플리케이션).

• 다른 권한 부여 유형(예: 권한 부여 코드 부여 또는 기기 코드 부여)을 구현할 수 없는 경우.

• 높은 수준의 보안 채널(예: 전송 계층 보안(TLS))을 통해 자격 증명이 전송되는 경우.

따라서 OAuth 2.0 공식 명세에서는 이 방식을 다른 모든 대안이 실현 불가능할 때의 최후의 수단으로만 사용할 것을 강력히 권고한다. 많은 주요 인증 서버 제공자들은 보안 정책을 강화하기 위해 이 흐름의 사용을 기본적으로 비활성화하거나 제한하는 경우가 많다.

Client Credentials Grant는 클라이언트 애플리케이션이 자신의 신원을 인증하여 액세스 토큰을 직접 획득하는 권한 부여 유형이다. 이 방식은 사용자(리소스 소유자)의 개입 없이, 클라이언트가 자신이 소유하거나 관리하는 보호된 리소스에 접근해야 할 때 사용된다. 주로 백그라운드에서 실행되는 서버 간 통신, 마이크로서비스 간 API 호출, 또는 사용자와 관계없는 데이터 처리 작업에 적합하다.

이 흐름에서는 권한 부여 서버에 클라이언트 ID와 클라이언트 비밀(또는 다른 인증 수단)을 제출하여 인증을 완료한다. 성공적으로 인증되면 권한 부여 서버는 클라이언트에게 직접 액세스 토큰을 발급한다. 이 과정에서 리프레시 토큰은 일반적으로 발급되지 않는다. 발급된 액세스 토큰은 클라이언트가 리소스 서버의 특정 API를 호출할 때 사용된다.

이 유형은 사용자 컨텍스트가 필요 없는 기계 대 기계(M2M) 인증에 최적화되어 있다. 따라서 권한 부여 코드 승인이나 암시적 승인과 같은 사용자 동의를 기반으로 하는 흐름과는 근본적으로 목적이 다르다. 구현 시 클라이언트 비밀과 같은 자격 증명을 안전하게 저장하고 관리하는 것이 가장 핵심적인 보안 요구사항이다.

Device Code Grant는 사용자가 입력 장치가 제한된 기기(예: 스마트 TV, 게임 콘솔, IoT 장치)에서 OAuth 2.0 인증을 완료할 수 있도록 설계된 권한 부여 유형이다. 이 방식은 기기가 사용자의 스마트폰이나 컴퓨터와 같은 보조 장치를 통해 인증을 완료하도록 한다. 주로 텍스트 입력이 어렵거나 웹 브라우저가 없는 환경에서 사용된다.

인증 흐름은 다음과 같이 진행된다. 먼저, 클라이언트 기기가 권한 부여 서버(Authorization Server)에 장치 코드 요청을 보낸다. 서버는 device_code, user_code, 그리고 일반적으로 verification_uri와 verification_uri_complete를 응답한다. 사용자는 다른 기기(예: 스마트폰)로 verification_uri에 접속하여 user_code를 입력하고, 평소처럼 자신의 계정으로 로그인 및 권한 승인을 수행한다. 이 동안 클라이언트 기기는 device_code와 client_id를 사용해 서버에 폴링(polling) 요청을 지속적으로 보내어, 사용자의 승인이 완료되고 액세스 토큰(Access Token)이 발급될 때까지 기다린다.

이 방식의 주요 특징과 장단점은 아래 표와 같다.

Device Code Grant는 OAuth 2.0의 확장 표준으로 정의되어 있으며, RFC 8628에 공식적으로 명세되어 있다. 이 방식을 사용하면 보안을 유지하면서도 다양한 종류의 장치에서 OAuth 2.0 생태계에 참여할 수 있게 된다.

OAuth 2.0 프로토콜은 널리 사용되지만, 잘못된 구현이나 구성은 여러 보안 위협에 노출될 수 있다. 주요 공격 유형으로는 교차 사이트 요청 위조(CSRF), 토큰 탈취 및 재전송 공격, 권한 부여 코드 가로채기, 클라이언트 애플리케이션 자체의 취약점을 이용한 공격 등이 있다.

교차 사이트 요청 위조(CSRF)는 특히 권한 부여 코드 승인(Authorization Code Grant) 흐름에서 중요한 위협이다. 공격자는 피해자가 이미 인증 서버(Authorization Server)에 로그인한 상태를 악용하여, 피해자의 브라우저를 통해 공격자의 클라이언트 애플리케이션에 권한을 부여하도록 유도할 수 있다. 이를 방지하기 위해 OAuth 2.0은 state 매개변수의 사용을 강력히 권장한다. 클라이언트는 인증 요청 시 임의의 state 값을 생성하여 전송하고, 인증 서버는 이 값을 그대로 리디렉션(redirect) URI에 포함하여 반환한다. 클라이언트는 반환받은 state 값이 원래 보낸 값과 일치하는지 반드시 검증해야 한다[5].

토큰 관련 공격도 흔하다. 액세스 토큰(Access Token)이 네트워크를 통해 평문으로 전송되거나 브라우저 저장소에 안전하지 않게 저장될 경우 탈취될 수 있다. 탈취된 토큰은 공격자가 정상 사용자인 것처럼 리소스 서버(Resource Server)에 접근하는 데 악용된다. 또한, 리프레시 토큰(Refresh Token)이 유출되면 공격자가 새로운 액세스 토큰을 무제한으로 발급받을 수 있어 더 심각한 위험을 초래한다. 토큰 탈취를 완화하기 위해 전송 계층 보안(TLS)의 사용은 필수적이며, 토큰의 수명을 짧게 설정하고 리프레시 토큰은 안전하게 저장해야 한다. 아래 표는 주요 공격 유형과 방어 메커니즘을 요약한 것이다.

이 외에도 클라이언트가 등록된 redirect_uri를 충분히 검증하지 않으면, 공격자가 권한 부여 코드나 토큰을 다른 도메인으로 전송하는 공격에 취약해진다. 또한, 공개 클라이언트(예: 단일 페이지 애플리케이션)의 경우, 암시적 승인(Implicit Grant) 흐름보다는 권한 부여 코드 승인 흐름과 PKCE 확장을 함께 사용하는 것이 현대적인 보안 모범 사례이다.

OAuth 2.0 구현 시 보안을 강화하기 위해 따라야 할 모범 사례는 다음과 같다.

클라이언트 측면에서는 리다이렉트 URI를 엄격하게 검증하고 사전에 등록된 URI만 허용해야 한다. 공격자가 제어하는 URI로 인증 코드가 전달되는 것을 방지하기 위함이다. 또한, 권한 부여 코드 교환 시 PKCE(Proof Key for Code Exchange)를 반드시 사용하여 인증 코드 가로채기 공격을 완화해야 한다. 클라이언트 자격 증명(클라이언트 ID와 비밀키)은 안전하게 저장하고, 공개 클라이언트(예: 모바일 앱, SPA)의 경우에는 클라이언트 비밀키를 사용하지 않는 흐름을 선택한다. 액세스 토큰은 가능한 짧은 수명을 부여하고, 리프레시 토큰은 서버 측에 안전하게 저장하거나, 발급 시 폐기 가능성을 고려해야 한다.

서버(인증 서버 및 리소스 서버) 측면에서는 모든 통신에 TLS(HTTPS)를 사용하는 것이 필수적이다. 토큰은 반드시 Bearer Token 사용법에 따라 전송하며, 토큰 자체에 민감한 정보를 포함하지 않는다. 인증 서버는 다양한 권한 부여 유형(Grant Types)에 대해 적절한 범위(Scope) 검증을 수행하고, 클라이언트 유형에 맞는 흐름만 허용해야 한다. 리소스 서버는 액세스 토큰의 서명, 만료 시간, 발행자(Issuer), 대상자(Audience) 등을 철저히 검증해야 한다. 또한, 정기적인 보안 감사와 취약점 점검을 통해 토큰 탈취, 재생 공격 등의 위협에 대비한다.

표준과 라이브러리를 최신 상태로 유지하는 것도 중요하다. OAuth 2.0 보안 고려사항(RFC 6819) 및 최신 권고 사항을 따르고, 검증된 공식 라이브러리를 사용하여 직접 구현 시 발생할 수 있는 보안 결함을 피해야 한다.

OpenID Connect(OIDC)는 OAuth 2.0 프레임워크 위에 구축된 인증 계층이다. OAuth 2.0이 주로 API 접근을 위한 권한 부여에 중점을 두는 반면, OIDC는 최종 사용자가 누구인지 확인하는 표준화된 방법을 제공한다. 이를 통해 클라이언트 애플리케이션은 사용자의 신원 정보를 안전하게 확인하고 그 기본 프로필 정보를 얻을 수 있다.

OIDC의 핵심은 ID 토큰이다. ID 토큰은 JSON Web Token(JWT) 형식으로 인코딩되며, 인증 서버가 서명하여 발행한다. 이 토큰에는 사용자의 신원을 주장하는 클레임(예: 사용자 식별자, 발행자, 만료 시간)이 포함되어 있다. 클라이언트는 이 토큰의 서명을 검증하여 인증 응답의 진위와 무결성을 확인한다. OAuth 2.0의 액세스 토큰이 '무엇을 할 수 있는가'(권한)를 나타낸다면, ID 토큰은 '누구인가'(신원)를 나타낸다.

OIDC는 몇 가지 표준 엔드포인트와 사용자 정보를 정의한다. 주요 엔드포인트로는 발견 문서를 제공하는 /.well-known/openid-configuration, 인증 요청을 처리하는 /authorize, 토큰을 교환하는 /token, 그리고 사용자 프로필 정보를 반환하는 /userinfo가 있다. 표준 프로필 클레임에는 sub(주체 식별자), name, email, picture 등이 포함된다.

이 표준은 싱글 사인온(SSO)과 연합 신원 관리의 기반이 되며, OAuth 2.0만으로는 부족했던 상호 운용 가능한 신원 정보 교환 문제를 해결한다. 결과적으로 현대 애플리케이션은 OAuth 2.0으로 리소스 서버에 대한 접근을 권한 부여하고, OIDC로 최종 사용자를 안전하게 인증하는 조합을 널리 사용한다.

JWT는 JSON 객체를 사용하여 당사자 간에 정보를 안전하게 전송하기 위한 개방형 표준(RFC 7519)이다. 이 정보는 디지털 서명되어 있으므로 신뢰할 수 있고 검증이 가능하다. JWT는 HMAC 알고리즘을 사용하는 비밀키나 RSA 또는 ECDSA를 사용하는 공개/개인 키 쌍으로 서명할 수 있다. 서명된 JWT는 토큰 내의 클레임 무결성을 검증하지만, 암호화된 JWT는 당사자 간에 추가적인 기밀성을 제공한다.

JWT는 점('.')으로 구분된 세 부분으로 구성된다.

* 헤더(Header): 일반적으로 토큰 유형(JWT)과 사용된 서명 알고리즘(예: HMAC SHA256 또는 RSA)의 두 부분으로 구성된다.

* 페이로드(Payload): 엔티티(일반적으로 사용자)에 대한 추가 데이터와 기타 클레임을 포함하는 클레임을 담는다. 클레임에는 등록된 클레임, 공개 클레임, 비공개 클레임의 세 종류가 있다.

* 서명(Signature): 인코딩된 헤더, 인코딩된 페이로드, 비밀키를 사용하여 생성된다. 서명은 메시지가 전송 중에 변경되지 않았음을 확인하는 데 사용된다.

JWT의 일반적인 구조는 다음과 같다.

xxxxx.yyyyy.zzzzz

OAuth 2.0 및 OpenID Connect에서 JWT는 액세스 토큰 또는 ID 토큰의 형식으로 널리 사용된다. 특히 OIDC의 ID 토큰은 반드시 JWT 형식이어야 한다. JWT는 자체적으로 필요한 모든 정보를 포함하는 독립적인 토큰이므로, 리소스 서버는 토큰의 서명만 검증하면 사용자 정보나 권한을 확인할 수 있다. 이는 매번 인증 서버에 토큰을 검증 요청할 필요가 없는 Stateless 아키텍처를 구현하는 데 유리하다. 그러나 토큰이 취소되기 전까지 만료 시간까지 유효하다는 점에서, 즉시적인 토큰 폐기가 어렵다는 단점도 존재한다.

클라이언트 등록은 OAuth 2.0 흐름을 시작하기 전에, 클라이언트 애플리케이션이 인증 서버에 자신의 정보를 등록하는 필수 절차이다. 이 과정을 통해 클라이언트는 고유한 식별자(클라이언트 ID)와 비밀(클라이언트 시크릿)을 발급받는다. 등록은 일반적으로 개발자가 인증 서버 제공자의 개발자 포털이나 관리 콘솔을 통해 수동으로 이루어진다.

등록 시 제공해야 하는 주요 정보는 다음과 같다.

등록이 완료되면 인증 서버는 client_id와 client_secret(컨피덴셜 클라이언트의 경우)을 발급한다. client_id는 공개되어도 무방하지만, client_secret은 서버 측에서 안전하게 보관해야 하는 비밀 키 역할을 한다. 퍼블릭 클라이언트(예: 단일 페이지 애플리케이션)의 경우 client_secret을 안전하게 저장할 수 없으므로, 이 값을 사용하지 않는 권한 부여 유형을 선택하거나 추가적인 보안 장치를 적용한다.

클라이언트 등록 정보는 이후 모든 OAuth 트랜잭션의 기초가 되며, 인증 서버가 클라이언트의 신원을 확인하고, 올바른 리디렉션 URI로만 응답을 보내며, 요청된 스코프의 적절성을 판단하는 데 사용된다. 등록 정보는 필요에 따라 갱신되거나 폐지될 수 있다.

권한 부여 코드 부여(Authorization Code Grant) 방식의 구현 예시는 일반적으로 다음과 같은 단계로 진행된다. 먼저, 클라이언트 애플리케이션은 사용자를 인증 서버(Authorization Server)의 인증 엔드포인트로 리디렉션한다. 이 요청에는 client_id, redirect_uri, response_type=code, 그리고 요청하는 권한 범위(scope)와 상태 값을 위한 state 매개변수가 포함된다.

사용자가 인증 서버에서 자신의 신원을 확인하고 요청된 권한에 동의하면, 인증 서버는 미리 등록된 redirect_uri로 사용자를 다시 클라이언트로 리디렉션한다. 이때 리디렉션 URL의 쿼리 문자열에 code(권한 부여 코드)와 state 매개변수가 첨부된다. 클라이언트는 반환된 state 값을 검증하여 요청의 위변조를 방지한다.

검증이 완료되면, 클라이언트는 획득한 code를 액세스 토큰으로 교환한다. 클라이언트는 인증 서버의 토큰 엔드포인트에 백엔드 간 요청을 보내며, 이 요청에는 grant_type=authorization_code, code, redirect_uri, 그리고 클라이언트 인증 정보(client_id와 client_secret)가 포함된다. 인증 서버는 코드의 유효성을 확인한 후, 응답 본문(보통 JSON 형식)으로 액세스 토큰, 리프레시 토큰, 토큰 유형 및 만료 시간을 발급한다. 클라이언트는 이 액세스 토큰을 사용하여 리소스 서버에 보호된 자원을 요청할 수 있다.