왜 암시적 흐름 대신 권한 부여 코드 흐름을 사용해야 하는가?

권한 부여 코드 흐름과 암시적 흐름은 OAuth 2.0 프로토콜의 승인 타입입니다. 이들은 권한 부여 서버로부터 접근 토큰을 얻는 데 사용됩니다. 접근 토큰을 통해, 애플리케이션이나 서비스는 사용자 대신 특정 작업을 수행하고 특정 자원에 접근할 수 있습니다.

OAuth란 무엇인가?#

OAuth에 대해 이야기할 때, 우리는 보통 OAuth 2.0을 언급합니다. "오픈 권한 부여"로 알려진 이 것은 웹사이트나 애플리케이션이 사용자를 대신하여 다른 웹 서비스의 자원을 이용할 수 있게 하는 확립된 프로토콜입니다. 이는 2012년에 OAuth 1.0을 대체했으며 이후 디지털 권한 부여의 널리 수용된 표준이 되었습니다. OAuth 2.0은 클라이언트 애플리케이션이 사용자 정보를 공개하지 않고 자원을 대표하는 자원과 상호 작용할 수 있는 특정 권한을 가질 수 있도록 제어된 접근을 용이하게 합니다.

주로 웹 환경에서 사용되지만, OAuth 2.0의 프레임워크는 다양한 클라이언트 형태로 확장됩니다. 여기에는 브라우저 기반 애플리케이션, 서버 측 웹 애플리케이션, 네이티브 또는 모바일 애플리케이션, 그리고 상호 연결된 기기들이 포함됩니다. 이러한 플랫폼 전반에서 위임된 접근을 관리하는 접근 방식을 자세히 설명합니다.

OAuth 2.0 프로토콜은 서로 다른 시나리오를 위해 설계된 네 가지 주요 승인 타입을 정의합니다:

• 권한 부여 코드: 서버 측 애플리케이션에 이상적이며, 이 흐름은 사용자를 권한 부여 서버로 리디렉션하여 로그인하도록 유도합니다. 인증이 완료되면, 사용자는 애플리케이션으로 다시 리디렉션되어 권한 부여 코드를 받으며, 이 코드는 접근 토큰으로 교환됩니다.
• 암시적: 접근 토큰이 추가적인 권한 부여 코드 교환 단계 없이 즉시 반환되는 클라이언트 측 또는 브라우저 기반 애플리케이션(예: 싱글 페이지 애플리케이션)에 적합합니다.
• 자원 소유자 비밀번호 자격 증명: 이 유형은 클라이언트 애플리케이션이 사용자의 자격 증명(사용자 이름과 비밀번호)을 제출하여 직접 접근 토큰을 요청하고 받을 수 있게 합니다. 보안 문제로 인해 덜 일반적이며, 보통 매우 신뢰할 수 있는 애플리케이션에서 사용됩니다.
• 클라이언트 자격 증명: 애플리케이션 자체가 클라이언트인 서버 간 통신에 사용됩니다. 이는 애플리케이션이 권한 부여 서버와 인증하고 자원이나 다른 서비스의 자원에 접근하기 위한 접근 토큰을 요청하는 것을 포함합니다.

많은 개발자가 어느 승인 타입을 선택할지 모르는 상황에서 두 가지 일반적으로 사용되는 승인 타입, 권한 부여 코드 승인 흐름과 암시적 승인 흐름을 살펴보겠습니다.

암시적 흐름은 어떻게 작동하나요?#

OAuth 2.0의 암시적 흐름은 대략 10년 전, 브라우저 기능이 오늘날과 크게 다를 때 개발되었습니다. 이 흐름은 주로 페이지가 로드된 서버에만 JavaScript가 요청을 보낼 수 있었던 과거 브라우저의 제한 사항 때문에 등장했습니다. 표준 OAuth 권한 부여 코드 흐름은 애플리케이션과 다른 도메인에 대해 호스팅되는 OAuth 서버의 토큰 엔드포인트에 POST 요청이 필요합니다. 이 제한은 이 흐름을 순수하게 JavaScript로 구현하는 것을 불가능하게 만들었습니다. 암시적 흐름은 POST 요청을 제거하여 리디렉션 프로세스에서 직접 접근 토큰을 제공함으로써 이를 우회했습니다.

요즘은 브라우저에서 교차 출처 리소스 공유(CORS)의 널리 보급으로, 암시적 흐름의 생성에 영향을 준 제약 사항이 더 이상 관련이 없습니다. CORS는 JavaScript가 요청을 다른 도메인 서버로 허용 제공자가 허용하도록 요청할 수 있게 합니다. 이 발전은 JavaScript 애플리케이션에서 권한 부여 코드 흐름을 사용하는 것을 가능하게 만듭니다.

암시적 흐름이 항상 권한 부여 코드 흐름보다 덜 안전한 대안으로 여겨졌다는 점을 인식하는 것이 중요합니다. 예를 들어, OAuth 사양은 보안 문제로 인해 암시적 흐름에서 리프레시 토큰의 반환을 지원하지 않습니다.

권한 부여 코드 흐름은 어떻게 작동하나요?#

이제 브라우저에서 권한 부여 코드 흐름을 사용할 수 있지만, 여전히 JavaScript 애플리케이션의 문제를 처리해야 합니다. 전통적으로, 권한 부여 코드 흐름은 접근 토큰을 위해 권한 부여 코드를 교환하는 데 클라이언트 시크릿을 사용합니다. 그러나 이를 JavaScript 애플리케이션에 포함하면서 비밀로 유지하는 것이 불가능합니다.

이 문제는 코드 교환을 위한 증명 키(PKCE) 확장으로 해결되었습니다(자세한 내용을 알아보기 위해 이 블로그를 읽어보세요). PKCE와 함께 하는 권한 부여 코드 흐름은 추가 단계를 추가하여 권한 부여 코드를 안전하게 보호할 수 있게 하며, 리디렉션 과정 중 코드가 도난되더라도 쓸모없게 만듭니다.

암시적 흐름의 단점#

위의 소개에서 우리는 암시적 흐름과 관련된 두 가지 주요 보안 위험을 볼 수 있습니다:

1. 암시적 흐름이 권한 부여 코드 흐름보다 덜 안전한 이유 중 하나는 클라이언트 인증이 없다는 것입니다. JavaScript 애플리케이션이 브라우저에서 실행되는 것과 같은 공개 클라이언트는 어떤 비밀도 보호할 수 없습니다. 따라서 공개 클라이언트의 인증을 요구하는 것은 의미가 없습니다. 클라이언트 자격 증명을 브라우저에서 소스 코드를 조사하는 방식으로 볼 수 있기 때문입니다. 클라이언트 인증이 필요하지 않은 경우, 클라이언트의 ID를 알고 있는 한 어떤 애플리케이션도 해당 클라이언트인 척할 수 있습니다.
2. 암시적 흐름은 접근 토큰을 URL 리디렉션을 통해 전달해야 하므로 다른 유형의 공격이 가능합니다. 예를 들어, 토큰이 URL의 쿼리 부분에 있는 경우 브라우저는 접근 토큰을 실수로 히스토리에 저장하지 못하도록 할 수 없습니다. 또한, 토큰이 포함된 전체 URL이 다른 서버로 전송되는 것을 막을 수 없습니다.

권한 부여 코드 흐름이 암시적 흐름의 보안 문제를 해결할 수 있나요?#

답은 예입니다:

1. 권한 부여 코드 흐름은 사용자 인증을 통해 얻은 권한 부여 코드를 클라이언트 자격 증명과 함께 사용하여 토큰 요청을 통해 접근 토큰을 검색하며, 이 과정은 HTTPS 연결 암호화로 보호됩니다.
2. 앞서 언급했듯이 PKCE 메커니즘을 도입함으로써, 권한 부여 코드와 클라이언트 자격 증명을 가로채더라도 올바른 코드 검증자가 없는 경우 접근 토큰을 얻을 수 없도록 합니다.

비즈니스에서 암시적 흐름을 현재 사용하고 있다면, PKCE가 통합된 권한 부여 코드 흐름으로 전환하는 것이 당신과 사용자 모두에게 더 나은 보안을 제공할 수 있습니다. 우리는 식별 시스템의 이주와 관리가 번거롭고 비용이 많이 들 수 있음을 이해하기에, 간단하고 사용하기 쉬우면서도 강력한 식별 관리 도구인 Logto를 만들었습니다. Logto는 사용자 로그인 과정에서 PKCE가 통합된 권한 부여 코드 흐름을 사용하여 사용자에게 최고의 보안 수준을 제공합니다.