이 페이지는 Cloud Translation API를 통해 번역되었습니다.

OAuth 2.0 소개

이 페이지는 Apigee 및 Apigee Hybrid에 적용됩니다.

OAuth 홈: OAuth 홈페이지에서 Google이 제공하는 OAuth 가이드의 개요를 참조하세요.

이 주제에서는 Apigee의 OAuth 2.0 기본 개요를 제공합니다.

OAuth 2.0이란?

OAuth 2.0에 특화된 책, 블로그, 사이트가 많이 있습니다. 먼저 IETF OAuth 2.0 사양을 검토하는 것이 좋습니다. 다음은 OAuth 2.0 IETF 사양 자체에서 제공되는 OAuth 2.0의 정의입니다.

"OAuth 2.0 승인 프레임워크를 사용하면 타사 애플리케이션이 리소스 소유자 및 HTTP 서비스 간의 승인 상호작용을 조정하여 리소스 소유자 대신 액세스하거나 타사 애플리케이션이 자체적으로 액세스하도록 허용하여 HTTP 서비스에 제한적으로 액세스하도록 할 수 있습니다."

반드시 알아 두어야 할 사항은 OAuth 2.0은 사용자가 앱에 로그인 사용자 인증 정보를 증명하지 않아도 앱이 사용자의 보호된 리소스(예: 은행 계좌 또는 사용자가 앱에서 액세스하려고 할 수 있는 기타 민감한 정보)에 제한적으로 액세스하도록 허용한다는 사실입니다.

팁: 여러 은행 계좌에 액세스할 수 있는 앱을 발견했다고 가정해 보겠습니다. 앱이 세금 관련 업무를 처리하거나 예산을 관리하는 데 사용될 수도 있습니다. 앱으로 관리하려는 은행 계좌가 3개 있고 계좌마다 사용자 이름과 비밀번호가 다릅니다. 이제 앱에서 은행 계좌에 액세스하려면 민감한 사용자 인증 정보가 필요합니다. 기본적으로 이러한 민감한 정보를 앱에 제공합니다. 앱이 비밀번호 및 사용자 이름을 소유하는 것을 신뢰할 수 있나요? 앱이 해킹되면 어떻게 될까요? 이제 각 계정의 은행 사용자 인증 정보를 변경해야 한다는 점을 기억해야 합니다. 이는 OAuth 2.0이 해결하는 근본적인 문제입니다. 자세한 내용은 아래를 참조하세요.

OAuth 2.0 흐름

다음은 OAuth 2.0 보안 프레임워크의 일반적인 흐름입니다. 이 주제에서는 이 흐름에 대해 OAuth 2.0의 작동 원리를 자세히 설명하는 다이어그램부터 자세히 살펴보겠습니다. 이 다이어그램에 사용된 용어에 익숙하지 않은 경우 이 섹션에서 간략히 알아보세요.

OAuth 2.0 보안 프레임워크의 일반적인 흐름

알아야 할 용어

클라이언트: 앱이라고도 합니다. 휴대기기 또는 기존 웹 앱에서 실행되는 앱일 수 있습니다. 앱은 리소스 소유자를 대신하여 보호된 애셋에 대해 리소스 서버에 요청을 보냅니다. 리소스 소유자는 보호된 리소스에 액세스할 수 있는 권한을 앱에 부여해야 합니다.
리소스 소유자: 최종 사용자라고도 합니다. 일반적으로 보호 대상 리소스에 대한 액세스 권한을 부여할 수 있는 사람(또는 다른 주체)입니다. 예를 들어 앱이 소셜 미디어 사이트 중 하나의 데이터를 사용해야 하는 경우 리소스 소유자만이 데이터에 대한 액세스 권한을 앱에 부여할 수 있습니다.
리소스 서버: 리소스 서버는 Facebook, Google 또는 Twitter와 같은 서비스, 인트라넷의 HR 서비스 또는 B2B 엑스트라넷의 파트너 서비스라고 생각하면 됩니다. Apigee는 OAuth 토큰 검증이 필요할 때마다 API 요청을 처리하는 리소스 서버입니다. 리소스 서버는 보호된 리소스를 앱에 제공하기 전에 일종의 승인을 요구합니다.
승인 서버: 승인 서버는 OAuth 2.0 사양을 준수하여 구현되며, 승인 부여 검증 및 리소스 서버에서 사용자 데이터에 액세스할 수 있는 권한을 앱에 부여하는 액세스 토큰 발급을 담당합니다. Apigee에서 토큰 엔드포인트를 구성할 수 있습니다. 이 경우 Apigee가 승인 서버의 역할을 수행합니다.
승인 부여: 최종 사용자를 대신하여 액세스 토큰을 검색할 수 있는 권한을 앱에 부여합니다. OAuth 2.0은 4가지 구체적인 '부여 유형'을 정의합니다. OAuth 2.0 부여 유형이란을 참조하세요.
액세스 토큰: 보호된 리소스에 액세스하는 데 사용되는 사용자 인증 정보 역할을 하는 긴 문자열입니다. 액세스 토큰이란?을 참조하세요.
보호된 리소스: 리소스 소유자가 소유한 데이터입니다. 예를 들면 사용자의 연락처 목록, 계정 정보, 기타 민감한 정보가 있습니다.

Apigee가 적합한 경우

OAuth 2.0을 사용하여 Apigee를 통해 프록시되는 모든 API를 보호할 수 있습니다. Apigee에는 인증 서버 구현이 포함되어 있으므로 액세스 토큰을 생성하고 검증할 수 있습니다. 개발자는 먼저 Apigee에 앱을 등록합니다. 등록된 앱은 4가지 권한 유형 상호작용을 통해 액세스 토큰을 요청할 수 있습니다.

Apigee는 각 부여 유형의 세부정보를 구현하는 다각적인 OAuthV2 정책을 제공하여 Apigee에서 OAuth를 비교적 쉽게 설정할 수 있습니다. 예를 들어 액세스 토큰 요청을 수신하고, 필요한 모든 사용자 인증 정보를 평가하고, 사용자 인증 정보가 유효한 경우 액세스 토큰을 반환하는 정책을 구성할 수 있습니다.

보안 API 프록시가 호출하는 리소스 서버는 방화벽 뒤에 있어야 합니다. 즉, API 프록시나 보안이 우수한 다른 API 이외의 방법을 통해 리소스에 액세스할 수 없어야 합니다.

OAuth 2.0 부여 유형이란?

부여 유형은 앱이 액세스 토큰을 얻기 위해 취할 수 있는 여러 경로 또는 상호작용이라고 생각하면 됩니다. 각 부여 유형은 1개 이상의 사용 사례를 처리하며, 각자의 니즈에 따라 사용할 부여 유형을 선택해야 합니다. 일반적으로 각 부여 유형에는 장단점이 있으며 비즈니스 사용 사례에 따라 절충점을 조정해야 합니다. 한 가지 중요한 고려사항은 데이터에 액세스할 앱의 신뢰도입니다. 일반적으로 타사 앱은 기업 내에서 개발되고 사용되는 앱보다 신뢰도가 낮습니다.

Apigee는 4가지 주요 OAuth 2.0 부여 유형을 지원합니다.

승인 코드 -- 가장 안전한 부여 유형으로 간주됩니다. 승인 서버가 액세스 토큰을 발급하려면 먼저 리소스 서버에서 승인 코드를 받아야 합니다. 앱에서 리소스 서버의 로그인 페이지로 브라우저를 열고 실제 계정(예: Facebook 또는 Twitter)에 로그인하도록 요청할 때 이 흐름이 나타납니다.

로그인에 성공하면 앱은 승인 서버와 액세스 토큰을 협상하는 데 사용할 수 있는 승인 코드를 수신합니다. 일반적으로 이 부여 유형은 앱이 클라이언트가 아닌 서버에 있는 경우에 사용됩니다. 클라이언트 앱이 리소스 서버에 대한 사용자 이름 또는 비밀번호를 처리하거나 확인하지 않기 때문에(즉, 예를 들어 앱이 Twitter 사용자 인증 정보를 확인하거나 처리하지 않음) 이 권한 유형은 매우 안전한 것으로 간주됩니다. 이러한 권한 부여 흐름은 3-legged OAuth라고도 합니다.

암시적 - 승인 코드의 약식 버전으로 간주됩니다. 일반적으로 이 부여 유형은 앱이 클라이언트에 있을 때 사용됩니다. 예를 들어 앱의 코드가 별도의 웹 서버에서 상주하며 실행되는 대신 자바스크립트 또는 다른 스크립팅 언어를 사용하여 브라우저에 구현됩니다. 이 부여 유형 흐름에서 승인 서버는 승인 코드를 먼저 발급하지 않고 사용자가 인증되면 액세스 토큰을 직접 반환합니다. 암시적 부여는 경우에 따라 앱 응답성을 개선할 수 있지만, IETF 사양에 설명된 것처럼 잠재적 보안 영향 대비 이러한 이점을 비교 검토해야 합니다.
리소스 소유자 비밀번호 사용자 인증 정보 -- 이 흐름에서는 승인 서버가 사용자의 사용자 이름/비밀번호를 확인하면 클라이언트에 액세스 토큰이 발급됩니다. 신뢰도가 높은 애플리케이션에는 이 흐름을 사용하는 것이 좋습니다. 기본적인 인증을 통한 이 흐름의 장점은 사용자가 사용자 이름/비밀번호를 한 번만 제시한다는 것입니다. 지금부터 액세스 토큰이 사용됩니다.
클라이언트 사용자 인증 정보 -- 클라이언트 앱이 자체적으로 작동하는 경우 사용을 고려합니다. 즉, 클라이언트가 리소스 소유자이기도 합니다. 이 부여 유형은 일반적으로 예를 들어 앱이 백엔드 데이터 스토리지 서비스에 액세스해야 할 때 사용됩니다. 앱은 서비스를 사용하여 작업을 해야 하고, 그렇지 않으면 서비스가 최종 사용자에게 보이지 않게 됩니다. 이 부여 유형의 경우 앱은 승인 서버에 클라이언트 ID와 클라이언트 보안 비밀번호 키를 제시하여 액세스 토큰을 받을 수 있습니다. 추가 단계는 필요하지 않습니다. 모든 API 프록시에 쉽게 구현할 수 있는 즉시 사용 가능한 클라이언트 사용자 인증 정보 솔루션을 제공합니다.

액세스 토큰이란 무엇인가요?

액세스 토큰은 보호된 리소스에 액세스하는 데 사용되는 사용자 인증 정보 역할을 하는 긴 문자열입니다. 리소스 토큰(Bearer 토큰이라고도 함)은 다음과 같이 승인 헤더에 전달됩니다.

$ curl -H "Authorization: Bearer UAj2yiGAcMZGxfN2DhcUbl9v8WsR" \
  http://myorg-test.apigee.net/v0/weather/forecastrss?w=12797282

리소스 서버는 액세스 토큰이 사용자 이름 및 비밀번호와 같은 사용자 인증 정보의 역할을 수행함을 이해합니다. 또한 액세스 토큰은 리소스 서버에서 데이터를 읽을 수는 있지만 작성 또는 삭제할 수 없는 등의 제한이 있는 상태로 발급될 수 있습니다. 예를 들어 앱의 보안이 침해되면 액세스 토큰이 취소될 수 있습니다. 이 경우 앱을 계속 사용하려면 새 액세스 토큰을 가져와야 합니다. 그러나 보호된 리소스 서버(예: Facebook 또는 Twitter)에서 사용자 이름이나 비밀번호를 변경할 필요는 없습니다.

액세스 토큰은 일반적으로 보안상의 이유로 만료일이 있습니다. 일부 부여 유형은 승인 서버가 갱신 토큰을 발급하도록 허용합니다. 따라서 이전 액세스 토큰이 만료되면 앱에서 새 액세스 토큰을 가져올 수 있습니다. 액세스 및 갱신 토큰에 대한 자세한 내용은 IETF OAuth 2.0 사양을 참조하세요.

범위를 통해 제한되는 액세스

OAuth 2.0은 범위 메커니즘을 통해 보호 된 리소스에 대한 제한된 액세스 권한을 앱에 부여할 수 있습니다. 예를 들어 앱은 특정 리소스에만 액세스할 수 있거나, 리소스를 업데이트할 수 있거나, 읽기 전용 액세스 권한만 있을 수 있습니다. 소위 3-legged OAuth 흐름에서 사용자는 일반적으로 동의 페이지를 통해 액세스 수준을 지정합니다(예: 사용자가 체크박스 또는 다른 메커니즘을 사용하여 범위를 선택하는 웹페이지).

앱 등록

모든 클라이언트(앱)는 액세스 토큰을 요청할 OAuth 2.0 승인 서버에 등록해야 합니다. 앱을 등록하면 키 집합이 다시 수신됩니다. 하나는 클라이언트 식별자라는 공개 키이고 다른 하나는 클라이언트 비밀번호라는 보안 비밀 키입니다. 이 키가 없으면 앱이 승인 서버에 대한 승인 코드 또는 액세스 토큰 요청을 실행할 수 없습니다. IETF OAuth 사양에서는 이러한 키를 클라이언트 ID와 클라이언트 보안 비밀번호라고 부르지만 Apigee UI에서는 이를 고객 ID와 고객 보안 비밀이라고 부릅니다. 모두 의미는 같습니다.

OAuth 2.0 사용 사례 요약

구체적인 사용 사례에 따라 구현하기로 선택해야 하는 OAuth 2.0 부여 유형 흐름이 달라집니다. 부여 유형별로 안전성이 다르기 때문입니다. 부여 유형은 클라이언트 앱의 신뢰도에 따라 선택해야 하며 다음 표에 설명된 대로 매우 심사숙고해야 합니다.

사용 사례	신뢰성	권장하는 OAuth 2.0 승인 부여 유형	설명
B2B(엑스트라넷), 인트라넷, 기타	내부 개발자 또는 API 제공업체와 신뢰할 수 있는 비즈니스 관계를 맺고 있는 개발자가 작성한 신뢰도가 높은 앱 사용자를 대신하여 리소스에 액세스해야 하는 앱	클라이언트 사용자 인증 정보	일반적으로 앱도 리소스 소유자 클라이언트 ID 및 클라이언트 보안 비밀번호 키 필요 앱을 서비스 제공업체에 등록해야 함
인트라넷 사이트, 포털	내부 또는 신뢰할 수 있는 타사 개발자가 작성한 신뢰할 수 있는 앱 좋은 예로 회사 HR 사이트에 로그인하여 보험 선택, 리뷰 제출, 개인 정보 변경이 있습니다.	비밀번호 암시적	클라이언트 ID, 보안 비밀, 사용자 이름 및 비밀번호가 필요합니다. 앱을 서비스 제공업체에 등록해야 함
공개적으로 사용 가능한 앱	신뢰할 수 없는 앱은 API 제공업체와 신뢰할 수 있는 비즈니스 관계를 맺고 있지 않은 타사 개발자가 작성한 것입니다. 예를 들어 공개 API 프로그램에 등록하는 개발자는 일반적으로 신뢰해서는 안 됩니다.	승인 코드	사용자가 타사 리소스 제공업체(예: Twitter, Facebook)에 로그인해야 함 앱에서 사용자 이름과 비밀번호를 볼 수 없음 앱을 서비스 제공업체에 등록해야 함
B2C	개별 최종 사용자(모바일 사용자)가 관여하고, 사용자 인증 정보가 휴대기기에 저장됩니다.	암시적	앱을 서비스 제공업체에 등록해야 함 사용자 인증 정보는 앱을 실행하는 기기에 저장됩니다.

OAuth 2.0과 API 키 보안 비교

API 키 검증을 사용하려면 앱이 Apigee로 키를 보내야 합니다. 키는 API 프록시와 연결된 Apigee 개발자 앱의 유효한 소비자 키여야 합니다. 어떤 이유로 클라이언트 앱이 프록시를 호출하는 권한을 취소해야 하는 경우 해당 고객 키를 취소해야 합니다. 이 키를 사용하는 클라이언트 앱도 API 프록시에 액세스할 수 없습니다. 반면 앱의 키를 취소하지 않고 언제든지 OAuth 토큰을 취소할 수 있습니다. 앱은 사용자를 대신하여 새 토큰을 요청할 수 있으며 토큰이 부여되면 앱이 API 프록시를 계속 사용할 수 있습니다.

API 키와 토큰의 또 다른 차이점은, 토큰에는 나중에 검색하고 사용할 수 있는 메타데이터 속성이 포함될 수 있다는 것입니다. 예를 들어 API를 호출하는 사용자의 ID를 저장하고 이를 사용하여 백엔드 대상 서비스 호출을 맞춤설정할 수 있습니다.

API 키 검증에 대한 자세한 내용은 API 키를 참조하세요. OAuth 토큰을 통해 커스텀 속성을 사용하는 방법은 토큰 및 승인 코드 맞춤설정을 참조하세요.

토큰 만료 및 삭제 시간이 디스크 저장소에 미치는 영향

OAuthV2 정책으로 새 OAuth 토큰을 생성할 때 ExpiresIn 속성으로 토큰의 만료 시간을 설정할 수 있습니다. 기본적으로 토큰은 토큰이 만료된 후 3일 후에 저장소에서 삭제됩니다. 48시간과 같이 긴 만료 시간을 설정하면 Cassandra의 디스크 공간 사용량이 예기치 않게 증가할 수 있습니다. 디스크 공간 과다 사용을 방지하려면 만료 시간을 더 짧게 설정하거나 (1시간 권장) 만료 후 지연 기간 3일을 더 짧은 기간으로 변경하는 구성을 설정할 수 있습니다.

Apigee Hybrid 고객은 재정의 파일에 다음 구성을 설정하여 기본 삭제 시간을 변경할 수 있습니다.

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "SECONDS"

여기서 SECONDS는 토큰이 만료된 후 Apigee에서 토큰을 삭제하기 위해 기다리는 시간(초)입니다. 이 스탠자를 따옴표를 포함하여 쓰여진 대로 정확하게 포함해야 합니다.

예를 들어 만료 후 1시간으로 삭제 시간을 설정하려면 다음을 실행합니다.

runtime:
  cwcAppend:
    "conf_keymanagement_oauth.access.token.purge.after.seconds": "3600"