암시적 플로우 vs. 권한 부여 코드 플로우: 왜 암시적 플로우는 쓸모없게 되었는가?

OAuth 2.0에 "권한 부여 코드 플로우"가 있는 이유는 무엇일까요, 이미 "암시적 플로우"가 있는데 말이죠? 이 두 가지 인증 유형의 세부 사항을 살펴보고 암시적 플로우 사용을 피해야 하는 이유를 알아봅시다.

Darcy Ye

Developer

1/3/2024

권한 부여 코드 플로우와 암시적 플로우는 웹 애플리케이션의 안전하고 효율적인 사용자 인증을 가능하게 하는 OAuth 2.0에서 가장 많이 사용되는 두 인증 유형입니다. 두 플로우 모두 사용자가 자신의 자격 증명을 직접 노출하지 않고 애플리케이션에 접근 권한을 부여할 수 있는 인증 프로세스를 구현합니다. 암시적 플로우는 처음에는 브라우저 제한 사항을 해결하기 위해 개발되었으나, 현대 웹 기술의 출현으로 인해 권한 부여 코드 플로우는 그 향상된 보안 기능 덕분에 많은 개발자들에게 선호되는 선택이 되었습니다.

이 기사에서는 이 두 인증 유형의 차이점을 살펴보고, 왜 암시적 플로우 대신 권한 부여 코드 플로우를 사용하는 것이 좋은지 설명하겠습니다.

OAuth 2.0이란 무엇인가?

이 두 인증 유형의 세부 사항을 살펴보기 전에, OAuth 2.0이 무엇인지, 그리고 왜 현대 웹 애플리케이션에 필수적인지 이해해봅시다.

OAuth에 대해 이야기할 때, 우리는 일반적으로 OAuth 2.0을 의미합니다. "Open Authorization"으로 알려진 이 프로토콜은 웹사이트나 애플리케이션이 사용자를 대신하여 다른 웹 서비스의 리소스를 사용할 수 있게 하는 프로토콜입니다. 2012년에 OAuth 1.0을 대체하였고, 이후로 디지털 인증의 널리 받아들여진 표준이 되었습니다. OAuth 2.0은 사용자의 로그인 정보를 공개하지 않고도 클라이언트 애플리케이션이 사용자를 나타내는 리소스와 상호작용할 수 있도록 특정 권한을 부여하는 설계를 가지고 있습니다.

주로 웹 환경에서 사용되지만, OAuth 2.0의 프레임워크는 다양한 클라이언트 형태로도 확장됩니다. 여기에 브라우저 기반 앱, 서버 측 웹 애플리케이션, 네이티브 또는 모바일 애플리케이션, 상호 연결된 장치 등이 포함되며, 이러한 플랫폼에서 대리 접근을 관리하는 접근 방식을 자세히 설명합니다. OAuth 2.0은 클라이언트 애플리케이션, 사용자, 권한 부여 서버 간의 인증 프로세스를 정의하기 위해 "인증 유형"의 개념을 도입합니다. 이 인증 유형은 클라이언트 애플리케이션이 사용자의 리소스에 접근하기 위해 액세스 토큰을 얻는 방법을 결정하기 위해 사용됩니다. OAuth 2.0의 가장 일반적인 인증 유형은 다음과 같습니다

권한 부여 코드: 모든 유형의 애플리케이션에 이상적이며, 특히 서버 측 웹 애플리케이션에 적합합니다. 클라이언트 애플리케이션은 권한 부여 코드를 액세스 토큰으로 교환하고, 안전하게 토큰을 관리할 수 있습니다.
암시적: 간소화된 플로우로, 보안 서버 구성 요소 없이 브라우저 기반 애플리케이션을 위해 설계되었습니다. 클라이언트 애플리케이션에게 빠르게 토큰을 전달하기 위해 만들어졌지만, 보안 문제로 인해 현재는 대부분 사용되지 않음으로 간주됩니다.
리소스 소유자 비밀번호 자격 증명: 사용자의 자격 증명(사용자 이름 및 비밀번호)을 제출하여 클라이언트 애플리케이션이 직접 액세스 토큰을 요청하고 받을 수 있게 합니다. 클라이언트 애플리케이션이 사용자의 자격 증명에 직접적으로 접근할 수 있기 때문에 이 유형도 사용되지 않음으로 간주되며, 모든 상황에서 피해야 합니다.
클라이언트 자격 증명: 애플리케이션 자체가 클라이언트인 경우 사용되며, 기계 대 기계 통신에 사용됩니다. 애플리케이션은 권한 부여 서버와 인증하고, 자신의 리소스나 다른 서비스의 리소스에 접근하기 위해 액세스 토큰을 요청합니다.

암시적 플로우란 무엇인가?

암시적 플로우는 액세스 토큰이 추가적인 권한 부여 코드 교환 단계 없이 리다이렉트 URI에 직접 클라이언트로 반환되는 간소화된 OAuth 2.0 플로우입니다. 브라우저 제한 사항으로 인해 토큰 엔드포인트로 서버 측 요청을 할 수 없는 웹 애플리케이션을 위해 초기에 설계되었습니다.

암시적 플로우는 어떻게 작동합니까?

사용자가 인증 프로세스를 시작하기 위해 클라이언트 애플리케이션의 버튼이나 링크를 클릭합니다.
클라이언트 애플리케이션은 사용자에게 원하는 접근 범위를 포함하여 권한 부여 서버로 리다이렉션합니다.
권한 부여 서버는 사용자에게 로그인하고 클라이언트 애플리케이션에 권한을 부여하도록 합니다.
성공적인 인증 및 권한 부여 후, 권한 부여 서버는 사용자의 브라우저를 클라이언트의 지정된 리다이렉트 URI로 돌려보내며, URL 프래그먼트에 액세스 토큰을 포함합니다.
클라이언트 애플리케이션은 URL 프래그먼트에서 액세스 토큰을 추출하여 리소스 서버에서 사용자의 리소스에 접근합니다.

암시적 플로우의 보안 위험

암시적 플로우는 여러 보안 취약점을 가지고 있습니다:

토큰 노출: 액세스 토큰이 URL 프래그먼트에 직접 클라이언트로 반환되어 악의적인 주체에 의해 쉽게 가로챌 수 있습니다. 이것은 액세스 토큰이 잠재적으로 도난되고 악용될 위험을 노출합니다.
CSRF 공격: 암시적 플로우는 사용자를 속여 그들의 계정에 대한 무단 접근 권한을 부여하도록 하는 악의적인 웹사이트에 의해 교차 사이트 요청 위조(CSRF) 공격에 취약합니다.

이러한 보안 문제로 인해, 암시적 플로우는 현대 웹 애플리케이션에 권장되지 않습니다. 대신, PKCE(코드 교환을 위한 증명 키)를 사용하는 권한 부여 코드 플로우가 안전한 사용자 인증을 위한 선호되는 선택입니다.

권한 부여 코드 플로우란 무엇인가?

반면에 권한 부여 코드 플로우는 권한 부여 프로세스를 두 단계로 분리한 보다 안전한 OAuth 2.0 플로우입니다: 클라이언트 애플리케이션은 먼저 권한 부여 서버로부터 권한 부여 코드를 받고, 그런 다음 코드를 액세스 토큰과 교환합니다. 이 플로우는 클라이언트 자격 증명을 안전하게 저장하고 액세스 토큰을 관리할 수 있는 서버 측 웹 애플리케이션을 위해 처음 설계되었습니다. PKCE 확장의 도입으로, 권한 부여 코드 플로우는 이제 브라우저 기반 애플리케이션에서도 사용할 수 있게 되었습니다.

서버 측 구성 요소를 가진 비공개 클라이언트를 위한 권한 부여 코드 플로우는 어떻게 작동합니까?

사용자가 인증 프로세스를 시작하기 위해 클라이언트 애플리케이션의 버튼이나 링크를 클릭합니다.
클라이언트 애플리케이션은 사용자에게 원하는 접근 범위를 포함하여 권한 부여 서버로 리다이렉션합니다.
권한 부여 서버는 사용자에게 로그인하고 클라이언트 애플리케이션에 권한을 부여하도록 합니다.
성공적인 인증 및 권한 부여 후, 권한 부여 서버는 클라이언트에게 권한 부여 코드를 반환합니다.
클라이언트 애플리케이션은 클라이언트 자격 증명을 사용하여 서버 대 서버 요청을 통해 권한 부여 코드를 액세스 토큰으로 안전하게 교환합니다.
권한 부여 서버는 권한 부여 코드와 클라이언트 자격 증명을 검증하고, 클라이언트에게 액세스 토큰을 반환합니다.
클라이언트 애플리케이션은 리소스 서버에서 사용자의 리소스에 액세스하기 위해 액세스 토큰을 사용합니다.

PKCE를 사용하는 공개 클라이언트를 위한 권한 부여 코드 플로우는 어떻게 작동합니까?

사용자가 인증 프로세스를 시작하기 위해 클라이언트 애플리케이션의 버튼이나 링크를 클릭합니다.
클라이언트 애플리케이션은 코드 검증기 및 코드 챌린지를 생성합니다.
클라이언트 애플리케이션은 코드 챌린지와 함께 사용자를 권한 부여 서버로 리다이렉션하여 인증합니다.
권한 부여 서버는 나중에 검증하기 위해 코드 챌린지를 저장합니다.
사용자는 인증하고 클라이언트 애플리케이션에 접근을 승인합니다.
권한 부여 서버는 클라이언트에게 권한 부여 코드를 반환합니다.
클라이언트 애플리케이션은 코드 검증기를 사용하여 서버 대 서버 요청을 통해 권한 부여 코드를 액세스 토큰으로 교환합니다.
권한 부여 서버는 저장된 코드 챌린지에 대해 권한 부여 코드 및 코드 검증기를 검증합니다.
권한 부여 서버는 클라이언트에게 액세스 토큰을 반환합니다.
클라이언트 애플리케이션은 리소스 서버에서 사용자의 리소스에 액세스하기 위해 액세스 토큰을 사용합니다.

PKCE 플로우에 대해 더 알아보세요.