💡 OAuth 1.0a와 OAuth 2.0은 OAuth 프로토콜의 두 가지 다른 버전입니다.
- OAuth 2.0은 또한 모바일 및 클라우드 기반 애플리케이션에 대한 지원이 더욱 우수하며, 토큰 만료 및 갱신 토큰과 같은 기능을 포함합니다. - 기능적으로 OAuth 2.0이 우수하나 OAuth 1.0a는 여전히 OAuth 2.0으로 업그레이드할 수 없는 레거시 시스템을 비롯해 널리 사용되고 있습니다.
💡 OAuth 1.0a과 OAuth 2.0의 차이
비교 분류
OAuth 1.0a
OAuth 2.0
출시일
2007
2012
프로토콜
Request/Token
Authorization/Token
토큰 유형
한 번만 사용 가능
다중 사용 가능
토큰 지속 기간
폐기되기 전까지
구성된 기간
토큰 갱신
없음
리프레시 토큰
서명 방법
HMAC-SHA1
다중 옵션
SSL 필수 여부
아니오
예
클라이언트 인증
서명
다중 옵션
부여 유형
없음
다중 옵션
모바일 지원
낮음
높음
보안
적은 보호 기능
더 많은 보호 기능
[ 더 알아보기 ]
💡 OAuth 1.0에 ‘a’가 붙은 이유는?
- OAuth 1.0은 2007년 릴리즈 되었고 OAuth 1.0a는 2010년에 릴리즈 되었습니다.
- OAuth 1.0a는 기존 버전에서 발견된 보안 취약점을 해결하기 위해 업데이트된 버전입니다. - 주요한 업데이트 사항은 고객이 인증 토큰과 액세스 토큰을 받을 때 서명된 요청을 HTTP POST로 전송했습니다. 그러나 이 방법은 악의적인 사용자가 고객의 인증 토큰과 액세스 토큰을 가로챌 수 있는 보안 취약점을 가지고 있었습니다.
- 이 취약점을 해결하기 위해 모든 인증 및 액세스 토큰 교환을 HTTP POST가 아니라 HTTP GET으로 수행하도록 변경했습니다. 이렇게 하면 고객의 인증 토큰과 액세스 토큰이 전송되는 URL이 서명될 수 있으므로 보안성이 향상됩니다.
💡 사용자가 특정 웹 사이트에 로그인하고 싶다고 가정을 하며 사용자는 서드파티 애플리케이션(Facebook, Github, Google, Microsoft)을 통해 로그인할 수 있습니다.
1. User enters credentials: 사용자는 서드파티 애플리케이션을 선택하면 로그인을 위해 해당 웹 사이트로 리다이렉션 됩니다. (User → Client)
2. Client passes credentials and its identification to authiorization server. Authiorization Server validates the information and returns an access token.: 로그인에 성공하면 특정 웹사이트에서 요청한 특정 데이터에 대한 액세스 권한을 부여할지 묻는 메시지가 표시되며 원하는 옵션을 선택하고 인증 코드 또는 오류 코드와 함께 특정 사이트로 리다이렉션 됩니다. (Client ↔ Authorization Server)
3. The Client uses access token to access resource server: 타사 리소스의 작업에 따라 로그인이 성공하거나 실패합니다. (Client ↔ Resource Server)
- 클라이언트가 사용자 인증을 받기 위해 인가 서버(Authorization Server)에 인증 코드를 요청하고 이를 이용하여 액세스 토큰(Access Token)을 발급받는 과정을 말합니다.
💡 권한 코드 승인 방식 (Authorization Code Grant) 동작과정
1. Access Application: 사용자는 앱에 접근하여 인증 및 권한 부여를 트리거합니다.
2. Authentication and Request Authorization: 앱은 사용자를 인증 서버로 리디렉션 하고, 사용자의 아이디와 비밀번호를 요청합니다. 이 과정에서, 사용자에게 처음으로 앱에 대한 권한 부여 페이지가 표시됩니다. 이 페이지에서 사용자는 앱이 사용자의 리소스에 접근하기 위한 권한을 선택할 수 있습니다.
3. Authentication and Grant Authorization: 클라이언트는 사용자를 인증하기 위해 Authorization Server에 인증 코드를 요청합니다.
4. Send Authorization Code: 사용자는 Authorization Server에 로그인하여 인증 코드를 받습니다.
5. Request Code Exchange for Token: 클라이언트는 Authorization Server에 액세스 토큰을 요청하고, 인증 코드와 함께 전송합니다.
- OAuth2 프로토콜에서 인증과 권한 부여를 담당하는 서버입니다. 클라이언트는 사용자의 권한을 인증 서버에 요청하고 인증 서버는 사용자의 동의를 얻어 액세스 토큰을 발급합니다. 이 액세스 토큰은 리소스 서버에서 사용자의 데이터를 가져오기 위한 권한 부여에 사용됩니다.
💡 리소스 서버(Resource Server)
- OAuth2 프로토콜에서 인증 서버로부터 발급받은 액세스 토큰을 사용하여 보호된 리소스에 대한 클라이언트의 요청을 인가하고 응답하는 서버입니다. 보호된 리소스는 사용자 정보와 같은 중요한 데이터를 포함할 수 있습니다.
- 클라이언트 애플리케이션이 Access Token을 직접 발급받는 것이 아니라 사용자 에이전트(웹 브라우저 등)를 통해 인가 과정을 거쳐 Access Token을 발급받는 방식을 의미합니다.
- Authorization Code Grant와는 달리 Access Token을 직접 발급받기 때문에 Access Token이 노출될 위험은 있습니다. 따라서 이 방식은 보안적인 취약점이 있으므로 권장되지 않습니다.
[ 더 알아보기 ]
💡 암시적 승인 방식 (Implicit Grant)이 보안적인 취약점이 발생되는 이유
1. Access Token이 노출될 가능성이 높습니다.
- 클라이언트 애플리케이션에서는 JavaScript를 통해 URL Fragment를 읽을 수 있습니다. 이 경우, 악의적인 공격자가 JavaScript를 이용하여 Access Token을 탈취할 수 있습니다.
2. Access Token의 수명이 무제한입니다.
- 암시적 승인 방식에서는 Access Token의 수명을 제어할 수 없습니다. Access Token은 사용자가 로그아웃하거나, 일정 기간이 지나기 전에는 만료되지 않습니다. 이는 Access Token이 탈취될 경우, 악의적인 공격자가 계속해서 해당 Access Token을 사용할 수 있다는 것을 의미합니다.
3. Access Token이 제한적인 범위로 사용되지 않을 수 있습니다.
- Access Token의 범위(scope)를 제어할 수 없습니다. 따라서, 클라이언트 애플리케이션에서는 Access Token을 원하는 대로 사용할 수 있습니다. 이는 권한이 없는 데이터에 접근할 수 있다는 것을 의미합니다.
4. Access Token이 클라이언트 시크릿 없이 발급됩니다.
- 클라이언트 시크릿을 사용하지 않습니다. 따라서, 클라이언트 애플리케이션이 Access Token을 발급받는 것을 막을 수 없습니다. 이는 악의적인 공격자가 클라이언트 애플리케이션을 통해 Access Token을 발급받을 수 있다는 것을 의미합니다.
💡 암시적 승인 방식 (Implicit Grant) 동작과정 1. Access client application: 클라이언트는 클라이언트 ID와 허가 유형 및 기타 선택적 매개 변수를 사용하여 액세스 토큰을 요청합니다.
2. User authorization request: 리소스 소유자가 권한 부여 서버와 직접 인증하므로 해당 자격 증명은 클라이언트와 공유되지 않습니다.
3. User authorizaties and authorizes the application: 권한 부여 서버는 URI 조각을 통해 액세스 토큰을 클라이언트로 보냅니다.
4. Redirect URL with access token in fragment: 클라이언트는 조각에서 토큰을 추출하고 액세스 토큰과 함께 API 요청을 리소스 서버로 보냅니다.
