OAuth 2 소개


소개

OAuth 2는 Facebook, GitHub 및 DigitalOcean과 같은 애플리케이션이 HTTP 서비스의 사용자 계정에 대한 제한된 액세스 권한을 얻을 수 있도록 하는 인증 프레임워크입니다. 사용자 계정을 호스팅하는 서비스에 사용자 인증을 위임하고 타사 응용 프로그램이 해당 사용자 계정에 액세스할 수 있도록 권한을 부여하는 방식으로 작동합니다. OAuth 2는 모바일 장치뿐만 아니라 웹 및 데스크톱 응용 프로그램에 대한 인증 흐름을 제공합니다.

이 정보 가이드는 애플리케이션 개발자를 대상으로 하며 OAuth 2 역할, 권한 부여 유형, 사용 사례 및 흐름에 대한 개요를 제공합니다.

OAuth 역할

OAuth는 네 가지 역할을 정의합니다.

  • 리소스 소유자: 리소스 소유자는 자신의 계정에 액세스할 애플리케이션을 인증하는 사용자입니다. 사용자 계정에 대한 애플리케이션의 액세스는 허용된 권한 범위(예: 읽기 또는 쓰기 액세스)로 제한됩니다.
  • 클라이언트: 클라이언트는 사용자의 계정에 액세스하려는 애플리케이션입니다. 그렇게 하기 전에 사용자의 승인을 받아야 하며 승인은 API에 의해 검증되어야 합니다.
  • 리소스 서버: 리소스 서버는 보호된 사용자 계정을 호스팅합니다.
  • 인증 서버: 인증 서버는 사용자의 ID를 확인한 다음 애플리케이션에 대한 액세스 토큰을 발급합니다.

애플리케이션 개발자의 관점에서 서비스의 API는 리소스 및 인증 서버 역할을 모두 수행합니다. 서비스 또는 API 역할로 이 두 역할을 결합하여 참조합니다.

추상 프로토콜 흐름

이제 OAuth 역할이 무엇인지 이해했으므로 역할이 일반적으로 서로 어떻게 상호 작용하는지에 대한 다이어그램을 살펴보겠습니다.

다이어그램의 단계에 대한 자세한 설명은 다음과 같습니다.

  1. 애플리케이션사용자에게 서비스 리소스에 액세스할 수 있는 권한을 요청합니다
  2. 사용자가 요청을 승인한 경우 애플리케이션은 승인 승인을 받습니다.
  3. 애플리케이션은 자체 ID 인증 및 권한 부여를 제시하여 인증 서버(API)에서 액세스 토큰을 요청합니다.
  4. 응용 프로그램 ID가 인증되고 권한 부여가 유효한 경우 권한 부여 서버(API)는 응용 프로그램에 대한 액세스 토큰을 발급합니다. 승인이 완료되었습니다.
  5. 애플리케이션리소스 서버(API)에서 리소스를 요청하고 인증을 위한 액세스 토큰을 제시합니다.
  6. 액세스 토큰이 유효하면 리소스 서버(API)가 애플리케이션에 리소스를 제공합니다

이 프로세스의 실제 흐름은 사용 중인 권한 부여 유형에 따라 다르지만 일반적인 개념입니다. 이후 섹션에서 다양한 보조금 유형을 살펴보겠습니다.

애플리케이션 등록

애플리케이션에서 OAuth를 사용하기 전에 애플리케이션을 서비스에 등록해야 합니다. 이는 서비스 웹 사이트의 개발자 또는 API 부분에 있는 등록 양식을 통해 수행되며, 여기에 다음 정보(및 아마도 응용 프로그램에 대한 세부 정보)를 제공합니다.

  • 애플리케이션 이름
  • 신청 웹사이트
  • 리디렉션 URI 또는 콜백 URL

리디렉션 URI는 사용자가 애플리케이션을 승인(또는 거부)한 후 서비스가 사용자를 리디렉션하는 위치이므로 인증 코드 또는 액세스 토큰을 처리하는 애플리케이션의 일부입니다.

클라이언트 ID 및 클라이언트 암호

애플리케이션이 등록되면 서비스는 클라이언트 식별자클라이언트 암호 형식으로 클라이언트 자격 증명을 발급합니다. 클라이언트 ID는 애플리케이션을 식별하기 위해 서비스 API에서 사용하는 공개적으로 노출된 문자열이며 사용자에게 표시되는 권한 부여 URL을 빌드하는 데에도 사용됩니다. 클라이언트 시크릿은 애플리케이션이 사용자 계정에 대한 액세스를 요청할 때 서비스 API에 애플리케이션의 ID를 인증하는 데 사용되며 애플리케이션과 API 간에 비공개로 유지되어야 합니다.

권한 부여

앞에서 설명한 추상 프로토콜 흐름에서 처음 네 단계는 권한 부여 및 액세스 토큰 획득을 다룹니다. 권한 부여 유형은 권한 부여를 요청하기 위해 애플리케이션에서 사용하는 방법과 API에서 지원하는 권한 부여 유형에 따라 다릅니다. OAuth 2는 각각 다른 경우에 유용한 세 가지 기본 권한 부여 유형을 정의합니다.

  • 인증 코드: 서버측 애플리케이션과 함께 사용
  • 클라이언트 자격 증명: API 액세스 권한이 있는 애플리케이션과 함께 사용
  • 장치 코드: 브라우저가 없거나 입력 제한이 있는 장치에 사용

경고: OAuth 프레임워크는 암호 부여 유형이라는 두 가지 추가 권한 부여 유형을 지정합니다. 그러나 이러한 권한 부여 유형은 둘 다 안전하지 않은 것으로 간주되며 더 이상 사용하지 않는 것이 좋습니다.

이제 다음 섹션에서 보조금 유형, 사용 사례 및 흐름에 대해 자세히 설명합니다.

부여 유형: 인증 코드

인증 코드 권한 부여 유형은 소스 코드가 공개적으로 노출되지 않는 서버측 애플리케이션에 최적화되어 있고 클라이언트 시크릿 기밀성을 유지할 수 있기 때문에 가장 일반적으로 사용됩니다. 이는 리디렉션 기반 흐름으로, 애플리케이션이 user-agent(즉, 사용자의 웹 브라우저)와 상호 작용하고 user-agent를 통해 라우팅되는 API 인증 코드를 수신할 수 있어야 함을 의미합니다. .

이제 인증 코드 흐름에 대해 설명하겠습니다.

1단계 - 인증 코드 링크

먼저 사용자에게 다음과 같은 인증 코드 링크가 제공됩니다.

https://cloud.digitalocean.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

다음은 이 예제 링크의 구성 요소에 대한 설명입니다.

  • **https://cloud.digitalocean.com/v1/oauth/authorize**: API 인증 엔드포인트
  • client_id=client_id: 애플리케이션의 클라이언트 ID(API가 애플리케이션을 식별하는 방법)
  • redirect_uri=CALLBACK_URL: 인증 코드가 부여된 후 서비스가 사용자 에이전트를 리디렉션하는 위치
  • response_type=code: 애플리케이션이 승인 코드 부여를 요청함을 지정합니다.
  • scope=read: 애플리케이션이 요청하는 액세스 수준 지정

2단계 - 사용자가 애플리케이션 승인

사용자가 링크를 클릭하면 먼저 서비스에 로그인하여 ID를 인증해야 합니다(이미 로그인한 경우 제외). 그런 다음 서비스에서 계정에 대한 애플리케이션 액세스를 인증하거나 거부하라는 메시지가 표시됩니다. 다음은 승인 애플리케이션 프롬프트의 예입니다.

이 특정 스크린샷은 DigitalOcean의 인증 화면이며 Thedropletbook 앱이 manicas@digitalocean.com 계정에 대한 읽기 액세스 권한을 요청하고 있음을 나타냅니다.

3단계 - 애플리케이션에서 인증 코드 수신

사용자가 애플리케이션 승인을 클릭하면 서비스는 인증 코드와 함께 클라이언트 등록 중에 지정된 애플리케이션 리디렉션 URI로 사용자 에이전트를 리디렉션합니다. 리디렉션은 다음과 같습니다(응용 프로그램이 dropletbook.com이라고 가정).

https://dropletbook.com/callback?code=AUTHORIZATION_CODE

4단계 - 애플리케이션 요청 액세스 토큰

애플리케이션은 클라이언트 암호를 포함한 인증 세부 정보와 함께 권한 부여 코드를 API 토큰 끝점에 전달하여 API에서 액세스 토큰을 요청합니다. 다음은 DigitalOcean의 토큰 엔드포인트에 대한 POST 요청의 예입니다.

https://cloud.digitalocean.com/v1/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

5단계 - 애플리케이션에서 액세스 토큰 수신

인증이 유효한 경우 API는 액세스 토큰(및 선택적으로 새로 고침 토큰)이 포함된 응답을 애플리케이션에 보냅니다. 전체 응답은 다음과 같습니다.

{"access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{"name":"Mark E. Mark","email":"mark@thefunkybunch.com"}}

이제 애플리케이션이 승인되었습니다. 토큰이 만료되거나 취소될 때까지 액세스 범위에 제한된 서비스 API를 통해 토큰을 사용하여 사용자 계정에 액세스할 수 있습니다. 새로 고침 토큰이 발급된 경우 원래 토큰이 만료된 경우 새 액세스 토큰을 요청하는 데 사용될 수 있습니다.

코드 교환을 위한 증명 키에 대한 참고 사항

퍼블릭 클라이언트가 인증 코드 부여 유형을 사용하는 경우 인증 코드를 가로챌 가능성이 있습니다. 코드 교환을 위한 증명 키(또는 PKCE, "pixie\처럼 발음됨)는 이러한 종류의 공격을 완화하는 데 도움이 되는 인증 코드 흐름의 확장입니다.

PKCE 확장에는 클라이언트가 모든 인증 요청에 대해 코드 검증기라고 하는 비밀 키를 만들고 기록하는 작업이 포함됩니다. 그런 다음 클라이언트는 코드 검증자를 코드 챌린지로 변환한 다음 이 코드 챌린지와 변환 방법을 동일한 인증 요청의 인증 엔드포인트로 보냅니다.

권한 부여 끝점은 코드 챌린지 및 변환 방법을 기록하고 앞에서 설명한 대로 권한 부여 코드로 응답합니다. 그런 다음 클라이언트는 원래 생성한 코드 검증기를 포함하는 액세스 토큰 요청을 보냅니다.

코드 검증기를 받은 후 Authorization Server는 클라이언트가 먼저 공유한 변환 방법을 사용하여 코드 챌린지로 변환합니다. 클라이언트가 보낸 코드 검증기에서 파생된 코드 챌린지가 인가 서버가 원래 기록한 것과 일치하지 않으면 인가 서버는 클라이언트 액세스를 거부합니다.

모든 클라이언트는 보안 향상을 위해 PKCE 확장을 사용하는 것이 좋습니다.

부여 유형: 클라이언트 자격 증명

클라이언트 자격 증명 부여 유형은 애플리케이션이 자체 서비스 계정에 액세스할 수 있는 방법을 제공합니다. 이것이 유용할 수 있는 경우의 예로는 애플리케이션이 등록된 설명 또는 리디렉션 URI를 업데이트하거나 API를 통해 서비스 계정에 저장된 다른 데이터에 액세스하려는 경우가 있습니다.

클라이언트 자격 증명 흐름

애플리케이션은 자격 증명, 클라이언트 ID 및 클라이언트 암호를 인증 서버에 전송하여 액세스 토큰을 요청합니다. 예제 POST 요청은 다음과 같을 수 있습니다.

https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

애플리케이션 자격 증명이 체크아웃되면 권한 부여 서버는 애플리케이션에 액세스 토큰을 반환합니다. 이제 애플리케이션이 자체 계정을 사용할 수 있는 권한이 부여되었습니다.

참고: DigitalOcean은 현재 클라이언트 자격 증명 부여 유형을 지원하지 않으므로 링크는 oauth.example.com의 가상 인증 서버를 가리킵니다.

부여 유형: 장치 코드

장치 코드 부여 유형은 브라우저가 없거나 입력이 제한된 장치가 액세스 토큰을 얻고 사용자 계정에 액세스할 수 있는 수단을 제공합니다. 이 권한 부여 유형의 목적은 사용자가 해당 장치에서 자신의 계정에 액세스할 수 있는 애플리케이션을 더 쉽게 인증할 수 있도록 하는 것입니다. 이것이 유용할 수 있는 경우의 예로는 사용자가 스마트 TV나 비디오 게임 콘솔과 같이 일반적인 키보드 입력이 없는 장치에서 비디오 스트리밍 애플리케이션에 로그인하려는 경우가 있습니다.

장치 코드 흐름

사용자는 브라우저가 없거나 텔레비전이나 셋톱 박스와 같은 입력 제한 장치에서 응용 프로그램을 시작합니다. 애플리케이션은 기기 인증 엔드포인트POST 요청을 제출합니다.

장치 코드 POST 요청의 예는 다음과 같을 수 있습니다.

POST https://oauth.example.com/device

client_id=CLIENT_id

장치 권한 부여 끝점은 실제로 장치를 인증하지 않으므로 장치 권한 부여 끝점은 인증 서버와 다릅니다. 대신 장치를 식별하는 데 사용되는 고유한 장치 코드를 반환합니다. 사용자 코드는 사용자가 노트북이나 휴대기기와 같이 인증하기 더 쉬운 시스템에 입력할 수 있습니다. 사용자 코드를 입력하고 장치를 인증하기 위해 사용자가 방문해야 하는 URL.

기기 인증 엔드포인트의 응답 예시는 다음과 같습니다.

{
  "device_code": "IO2RUI3SAH0IQuESHAEBAeYOO8UPAI",
  "user_code": "RSIK-KRAM",
  "verification_uri": "https://example.okta.com/device",
  "interval": 10,
  "expires_in": 1600
}

장치 코드는 판독기가 모바일 장치에서 스캔할 수 있는 QR 코드일 수도 있습니다.

그런 다음 사용자는 지정된 URL에 사용자 코드를 입력하고 계정에 로그인합니다. 그런 다음 장치가 자신의 계정에 액세스하도록 승인할 수 있는 동의 화면이 표시됩니다.

사용자가 확인 URL을 방문하여 코드를 입력하는 동안 장치는 오류 또는 인증 토큰을 반환할 때까지 액세스 엔드포인트를 폴링합니다. 장치가 너무 자주 폴링하는 경우(slow_down 오류), 사용자가 아직 요청을 승인 또는 거부하지 않은 경우(authorization_pending 오류) 액세스 엔드포인트가 오류를 반환합니다. , 사용자가 요청을 거부했거나(access_denied 오류) 토큰이 만료된 경우(expired_token 오류).

그러나 사용자가 요청을 승인하면 액세스 엔드포인트는 인증 토큰을 반환합니다.

참고: 다시 말하지만 DigitalOcean은 현재 장치 코드 부여 유형을 지원하지 않으므로 이 예제의 링크는 oauth.example.com의 가상 인증 서버를 가리킵니다.

액세스 토큰 사용 예

애플리케이션에 액세스 토큰이 있으면 토큰이 만료되거나 취소될 때까지 액세스 범위로 제한된 API를 통해 사용자 계정에 액세스하기 위해 토큰을 사용할 수 있습니다.

다음은 curl을 사용하는 API 요청의 예입니다. 여기에는 액세스 토큰이 포함되어 있습니다.

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN""https://api.digitalocean.com/v2/$OBJECT"

액세스 토큰이 유효하다고 가정하면 API는 API 사양에 따라 요청을 처리합니다. 액세스 토큰이 만료되었거나 유효하지 않은 경우 API는 invalid_request 오류를 반환합니다.

새로 고침 토큰 흐름

액세스 토큰이 만료된 후 이를 사용하여 API에서 요청하면 잘못된 토큰 오류가 발생합니다. 이때 기존 엑세스 토큰을 발급받을 때 새로 고침 토큰이 포함되어 있었다면 인가 서버에 새로운 엑세스 토큰을 요청할 때 사용할 수 있다.

다음은 새 액세스 토큰을 얻기 위해 새로 고침 토큰을 사용하는 POST 요청의 예입니다.

https://cloud.digitalocean.com/v1/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

결론

이 가이드를 따르면 OAuth 2의 작동 방식과 특정 권한 부여 흐름을 사용해야 하는 경우를 이해할 수 있습니다.

OAuth 2에 대해 자세히 알아보려면 다음과 같은 유용한 리소스를 확인하세요.

  • 사용자 또는 개발자로서 DigitalOcean에서 OAuth 인증을 사용하는 방법
  • DigitalOcean API v2 사용 방법
  • DigitalOcean OAuth API 참조 문서
  • OAuth 2.0 인증 프레임워크