클라이언트 자격 증명 흐름

OAuth 2는 애플리케이션이 Facebook, GitHub 및 DigitalOcean과 같은 HTTP 서비스의 사용자 계정에 제한적으로 액세스할 수 있도록 하는 인증 프레임워크입니다. 이는 사용자 계정을 호스팅하는 서비스에 사용자 인증을 위임하여 제3자 애플리케이션이 사용자 계정에 액세스할 수 있도록 하는 방식으로 작동합니다. OAuth 2는 웹, 데스크톱 및 모바일 애플리케이션에서 작동합니다.

이 문서는 애플리케이션 개발자를 대상으로 하며 OAuth 2의 역할, 인증 유형 및 일반적인 사용 사례에 대한 개요를 제공합니다.

OAuth 역할부터 시작하겠습니다!

OAuth 역할

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

리소스 소유자
고객
리소스 서버
인증 서버

리소스 소유자: 사용자

리소스의 소유자는 다음과 같습니다. 사용자, 이는 권한을 부여합니다 애플리케이션귀하의 계정에 액세스하려면. 사용자 계정에 대한 애플리케이션의 액세스는 부여된 인증 권한(예: 읽기 또는 쓰기 액세스)의 범위로 제한됩니다.

리소스/인증 서버: API

리소스 서버는 사용자 계정의 보호된 데이터를 직접 저장하고 인증 서버는 제공된 정보의 진위 여부를 검증합니다. 사용자을 선택한 다음 다음에 대한 인증 토큰을 생성합니다. 애플리케이션, 애플리케이션이 사용자 데이터에 액세스하는 데 도움이 됩니다.

애플리케이션 개발자의 관점에서 서비스 API는 리소스 서버 역할과 Authorization 서버 역할을 동시에 수행한다. 또한 우리는 이 두 가지 역할을 하나로 간주하여 이를 호출할 것입니다. 서비스또는 API.

고객: 애플리케이션

클라이언트는 애플리케이션계정에 액세스하려는 사람 사용자. 액세스하려면 먼저 사용자가 애플리케이션을 승인해야 하며 API에서 승인을 받아야 합니다.

이제 OAuth에서 사용되는 역할에 대한 아이디어를 얻었으므로 이들이 서로 상호 작용하는 방식에 대한 다이어그램을 살펴보겠습니다.

이 다이어그램의 일련의 단계에 대한 설명을 고려하세요.

애플리케이션요청 사용자리소스 서버에 대한 액세스 권한을 부여합니다.
만약에 사용자요청을 승인하고, 애플리케이션허가 승인을 받습니다.
애플리케이션에서 인증 토큰을 요청합니다. 인증 서버(API) 자신에 대한 정보와 사용자의 승인 권한을 제공합니다.
애플리케이션이 인증되고 승인권한이 유효한 경우, 인증 서버(API)는 애플리케이션에 대한 액세스 토큰을 생성합니다. 인증 절차가 완료되었습니다.
애플리케이션리소스를 요청합니다. 리소스 서버(API) 인증을 위한 액세스 토큰을 제공합니다.
토큰이 유효한 경우, 리소스 서버(API)는 요청된 리소스를 제공합니다. 애플리케이션.

설명된 프로세스의 실제 단계는 사용된 인증 권한 유형에 따라 다를 수 있지만 일반적으로 프로세스는 설명된 것과 유사합니다. 다음으로 다양한 유형의 인증 권한을 살펴보겠습니다.

애플리케이션 등록

애플리케이션에서 OAuth 사용을 시작하기 전에 서비스에 애플리케이션을 등록해야 합니다. 이는 서비스 웹사이트의 "개발자" 또는 "API" 섹션에 등록하여 수행되며, 여기에서 다음 정보(애플리케이션에 대한 일부 세부 정보 포함)를 제공해야 합니다.

애플리케이션 이름
신청 홈페이지
리디렉션 URL 또는 콜백 URL

리디렉션 URL은 애플리케이션 승인(또는 승인 거부) 후 서비스가 사용자를 리디렉션하는 URL입니다.

클라이언트 ID 및 클라이언트 비밀번호

애플리케이션을 등록한 후 서비스는 클라이언트 자격 증명(클라이언트 ID 및 클라이언트 비밀번호)을 생성합니다. 클라이언트 ID는 서비스 API에서 애플리케이션을 식별하는 데 사용되며 사용자를 위한 인증 URL을 생성하는 데에도 사용되는 공개적으로 액세스 가능한 문자열입니다. 클라이언트 시크릿은 애플리케이션이 사용자 계정에 대한 액세스를 요청할 때 서비스 API에 대해 애플리케이션의 ID를 인증하는 데 사용됩니다. 클라이언트 비밀번호는 애플리케이션과 API에만 알려져야 합니다.

승인 권한

안에 추상 프로토콜 설명위의 처음 네 단계에서는 인증 권한 및 액세스 토큰 생성 문제를 다룹니다. 승인 권한 유형은 애플리케이션에서 사용하는 승인 요청 방법과 API에서 지원하는 권한 유형에 따라 다릅니다. OAuth 2는 네 가지 유형을 정의하며 각 유형은 특정 상황에서 유용합니다.

인증 코드: 서버측 애플리케이션과 함께 사용됩니다.
절대적인: 모바일 또는 웹 애플리케이션(사용자 장치에서 실행되는 애플리케이션)에서 사용됩니다.
자원 소유자 비밀번호 자격 증명: 서비스 자체의 일부인 애플리케이션과 같이 신뢰할 수 있는 애플리케이션에서 사용됩니다.
클라이언트 자격 증명: 애플리케이션이 API에 접근할 때 사용됩니다.

인증 권한 유형: 인증 코드

인증 코드가장 일반적인 유형의 승인 권한 중 하나입니다. 서버 애플리케이션, 애플리케이션 소스 코드는 어디에 있고 클라이언트 비밀번호외부인이 접근할 수 없습니다. 이 경우 프로세스는 리디렉션을 기반으로 합니다. 즉, 애플리케이션은 다음과 상호 작용할 수 있어야 합니다. 사용자 에이전트(user-agent), 예를 들어 웹 브라우저를 통해 사용자 에이전트를 통해 리디렉션된 API 인증 코드를 받습니다.

다이어그램에서 프로세스를 설명하겠습니다.

1단계: 인증코드로 연결

https://cloud.?response_type=code&client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read

: API 인증 엔드포인트입니다.
클라이언트_ID=CLIENT_ID: 애플리케이션 클라이언트 ID(이 ID를 사용하여 API는 어떤 애플리케이션이 액세스를 요청하는지 이해합니다).
리디렉션_uri=콜백_URL: 인증코드 발급 후 서비스가 사용자 에이전트(브라우저)를 리디렉션하는 URL입니다.
response_type=코드: 애플리케이션이 인증 코드를 사용하여 접근을 요청하고 있음을 나타냅니다.
범위=읽기: 애플리케이션 액세스 수준을 설정합니다(이 경우 읽기 액세스).

3단계: 애플리케이션이 인증 코드를 받습니다.

사용자가 "애플리케이션 인증"을 선택하면 서비스는 클라이언트 등록 단계에서 지정된 리디렉션 URL로 사용자 에이전트(브라우저)를 리디렉션합니다. 인증 코드). 링크는 비슷해 보입니다(이 예에서는 애플리케이션을 “dropletbook.com”이라고 함).

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

4단계: 애플리케이션이 액세스 토큰을 요청합니다.

애플리케이션은 인증 코드와 인증 정보(포함)를 전송하여 API에서 액세스 토큰을 요청합니다. 클라이언트 비밀번호) 서비스. 다음은 DigitalOcean 토큰을 받기 위한 POST 요청의 예입니다.

https://cloud.?client_id=CLIENT_ID &client_secret=CLIENT_SECRET &grant_type=authorization_code&code=AUTHORIZATION_CODE &redirect_uri=CALLBACK_URL

5단계: 애플리케이션이 액세스 토큰을 받습니다.

("access_token":"ACCESS_TOKEN ","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN ","scope":"read","uid":100101,"info":( "이름":"마크 E. 마크","이메일":" [이메일 보호됨]"}}

이제 신청서가 승인되었습니다! 토큰이 만료되거나 토큰이 취소될 때까지 토큰을 사용하여 지정된 액세스 제한이 있는 서비스 API를 통해 사용자 계정에 액세스할 수 있습니다. 액세스 토큰 새로 고침 토큰이 생성된 경우 이전 토큰이 만료되면 새 액세스 토큰을 얻는 데 사용할 수 있습니다.

승인 권한 유형: 암시적

암시적 인증 권한 유형은 개인 정보 보호가 필요한 모바일 및 웹 애플리케이션(웹 브라우저에서 실행되는 애플리케이션)에서 사용됩니다. 클라이언트 비밀번호보장할 수 없습니다. 암시적 권한 유형도 사용자 에이전트 리디렉션을 기반으로 하며, 여기서 액세스 토큰은 사용자 에이전트에 전달되어 애플리케이션에 전달됩니다. 그러면 사용자 장치와 사용자 장치의 다른 응용 프로그램에서 토큰을 사용할 수 있게 됩니다. 또한 이러한 유형의 인증 권한은 애플리케이션의 ID를 인증하지 않으며 프로세스 자체는 리디렉션 URL(이전에 서비스에 등록된)에 의존합니다.

프로세스는 다음과 같습니다. 애플리케이션이 사용자에게 인증을 요청한 다음, 인증 서버가 액세스 토큰을 사용자 에이전트에 전달하고, 사용자 에이전트는 이 토큰을 애플리케이션에 전달합니다. 다음으로 프로세스를 자세히 설명하겠습니다.

1단계: 암시적 승인 링크

암시적 인증 권한 유형을 사용하면 사용자에게 API에서 토큰을 요청하는 링크가 제공됩니다. 이 링크는 요청하는 점을 제외하면 이전 방법(인증 코드 포함)에 대한 링크와 거의 동일해 보입니다. 토큰코드 대신(참고 응답 유형"토큰"):

https://cloud.?response_type=token&client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read

2단계: 사용자가 애플리케이션을 승인합니다.

사용자가 링크를 클릭하면 먼저 로그인하여 신원을 확인해야 합니다(물론 아직 로그인하지 않은 경우). 그런 다음 서비스는 사용자 계정에 액세스하기 위해 애플리케이션에 대한 인증을 승인하거나 거부하라는 메시지를 사용자에게 표시합니다. 그러한 대화의 예가 아래에 나와 있습니다.

3단계: 사용자 에이전트는 리디렉션 URI에서 액세스 토큰을 얻습니다.

https://dropletbook.com/callback#token=ACCESS_TOKEN

4단계: 사용자 에이전트는 리디렉션 URI를 따릅니다.

사용자 에이전트는 액세스 토큰을 저장하는 동안 리디렉션 URI를 따릅니다.

5단계: 애플리케이션이 액세스 토큰 검색 스크립트를 실행합니다.

애플리케이션은 사용자 에이전트에 의해 저장된 전체 리디렉션 URI에서 액세스 토큰을 추출하는 스크립트가 포함된 웹 페이지를 반환합니다.

6단계: 액세스 토큰이 애플리케이션에 전달됩니다.

사용자 에이전트는 액세스 토큰 추출 스크립트를 실행한 다음 추출된 토큰을 애플리케이션에 전달합니다.

이제 신청서가 승인되었습니다! 토큰이 만료되거나 토큰이 취소될 때까지 토큰을 사용하여 지정된 액세스 제한이 있는 서비스 API를 통해 사용자 계정에 액세스할 수 있습니다.

승인 권한 유형: 리소스 소유자 자격 증명

이러한 유형의 인증 권한을 통해 사용자는 서비스에서 자신의 인증 데이터(사용자 이름 및 비밀번호)를 애플리케이션에 직접 제공합니다. 그러면 애플리케이션은 수신된 사용자 자격 증명을 사용하여 서비스에서 액세스 토큰을 얻습니다. 이러한 유형의 인증 권한은 다른 옵션을 사용할 수 없는 경우에만 사용해야 합니다. 또한 이 유형의 권한은 사용자가 애플리케이션을 신뢰하는 경우(예: 서비스 자체 또는 사용자 운영 체제의 일부인 경우)에만 사용해야 합니다.

리소스 소유자 자격 증명을 사용한 프로세스

사용자가 애플리케이션에 자격 증명을 제공하면 애플리케이션은 인증 서버에 액세스 토큰을 요청합니다. POST 요청의 예는 다음과 같습니다.

https://oauth.example.com/token?grant_type=password&username=USERNAME &password=PASSWORD &client_id=CLIENT_ID

주목: DigitalOcean은 현재 리소스 소유자 자격 증명을 사용하는 인증 권한 유형을 지원하지 않으므로 위의 링크는 가상의 인증 서버 "oauth.example.com"을 가리킵니다.

인증 권한 유형: 클라이언트 자격 증명

클라이언트 자격 증명 승인 권한 유형을 사용하면 애플리케이션이 자체 서비스 계정에 액세스할 수 있습니다. 예를 들어 애플리케이션이 자체 서비스 등록 정보 또는 리디렉션 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"을 가리킵니다.

액세스 토큰 사용 예시

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

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

컬 -X POST -H "권한 부여: Bearer ACCESS_TOKEN "" https://api.site/v2/$OBJECT "

액세스 토큰이 유효하면 API는 수신된 요청을 처리합니다. 액세스 토큰이 만료되었거나 토큰이 유효하지 않은 경우 API는 "invalid_request" 오류를 반환합니다.

액세스 토큰 새로 고침

액세스 토큰이 만료되면 이를 사용하는 모든 API 요청은 "잘못된 토큰 오류"를 반환합니다. 액세스 토큰을 생성할 때 새로 고침 토큰도 생성된 경우, 새로 고침 토큰을 사용하여 인증 서버에서 새 액세스 토큰을 얻을 수 있습니다.

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

https://cloud.?grant_type=refresh_token&client_id=CLIENT_ID &client_secret=CLIENT_SECRET &refresh_token=REFRESH_TOKEN

결론

이것으로 OAuth 2에 대한 개요를 마칩니다. 이제 OAuth 2의 작동 방식과 기존 인증 권한 유형을 사용하는 시기 및 방법에 대한 기본적인 이해를 갖추었습니다.

OAuth 2에 대해 자세히 알아보려면 다음 문서를 확인하는 것이 좋습니다.

고객을 배려하는 Invola 서비스 팀은 OAuth 2.0 기술을 사용하여 메일에 대한 직접 연결을 구현했습니다.

이 기사에서는 이것이 무엇인지, 어떻게 작동하는지, 사용자 데이터 보안에 어떤 영향을 미치는지 설명합니다.
기술적인 내용은 생략하고 일반 사용자가 이해하기 쉬운 언어로 기술의 본질을 전달하겠습니다.

서비스의 일반 사용자는 때때로 그것이 어땠는지 알고 있습니다. 이메일 중복 사용이 불편해요, 종종 그에게 또 다른 편지를 보내는 것을 잊어 버렸습니다. 우리는 메일에 직접 연결하기 위해 송장 및 상업용 송장 수신 알고리즘을 재고해 달라는 편지를 받았습니다.

프로그래머와 보안 전문가의 몇 주간의 유익한 작업 끝에 인증 알고리즘 구현그리고 지금 주요 연결 방법입니다서비스를 제공하는 클라이언트.

OAuth란 무엇입니까?

무미건조한 기술 용어로 말하면 이는 한 서비스(이 경우 Invola)에 다른 서비스(메일 액세스)의 사용자 리소스에 액세스할 수 있는 권한을 부여할 수 있는 인증 프로토콜입니다.

사용자는 자신의 개인 데이터에 대한 무단 접근이 불가능하다는 것을 확신할 수 있기 때문에 애플리케이션을 신뢰할 더 많은 이유가 있습니다. 사용자의 로그인과 비밀번호 없이, 응용 프로그램은 다음을 수행할 수 있습니다.오직 그 행위데이터로 사용자가 허용한 것, 그리고 다른 사람은 없습니다.

간단히 말해서 Invola 서비스는 로그인 및 비밀번호를 요구하지 않고 액세스 권한을 요청하지 않고 메일에 연결하여 송장 및 상업 제안을 수신합니다. 확인하면 사용자가 직접 취소할 때까지 또는 애플리케이션이 존재하고 활성화되어 있는 동안 애플리케이션에 액세스할 수 있습니다.

Invola와 메일 서버 간의 통신은 액세스 토큰(4-5단계)을 사용합니다. 이 토큰은 한 시간 후에 자동으로 만료되고 필요에 따라 업데이트됩니다(사용자 개입 없이 Invola 소프트웨어에 의해 자동으로).

이제 보안과 그 이유에 대해 이야기해 보겠습니다. 로그인/비밀번호 인증보다 OAuth 인증이 선호됩니다..

귀하의 계정(mail.ru, gmail.com)에 액세스하기 위한 로그인 및 비밀번호가 포함된 서비스를 제공하면 실제로는 전체 계정에 대한 비밀번호를 제공하는 것입니다. 기타 개인 데이터).

OAuth를 통해 액세스 권한 부여당신 자신 액세스할 리소스 제어계정 당신은 액세스 권한을 부여. Invola에 연결할 때 요청되는 권한의 예를 살펴보겠습니다.

"메일 보기 및 관리" - 청구서 및 CP 자동 수령을 위해, " 주소 보기" – 상자의 이메일 주소를 얻으려면 " 프로필보기" – 사용자 이름을 얻기 위해 필요합니다(등록 단계에서 필요함).

안타깝게도, 모든 메일 서버는 아닙니다(법인 포함) 지원 승인기술로 OAuth, 특히 인기 있는 서비스인 Yandex.Mail. 메일이 Yandex에 있는 경우 현재는 로그인 비밀번호를 통해서만 당사 서비스에 연결할 수 있습니다.

보안에 대해 조금.

우리는 기밀 데이터의 유출이나 고객, 금융 거래, 개인 서신에 관한 데이터에 대한 무단 접근이 비즈니스에 얼마나 중요한지 잘 알고 있습니다. 데이터 보안은 우리 업무의 주요 우선순위 중 하나입니다..

액세스 토큰과 메일 액세스를 위한 비밀번호는 동적 키를 기반으로 한 암호화 체계를 사용하여 안전한 전용 데이터베이스 서버에 저장됩니다.

결과적으로 당사 직원은 어떤 상황에서도 사용자의 메일 서버 및 서신에 액세스할 수 없다는 점에 주목할 필요가 있습니다.

모든 커뮤니케이션사용자와 서비스 간, 서비스와 메일 서버 간 보안 SSL 채널을 통해 수행됨즉, 양방향으로 전송되는 모든 데이터는 강력한 암호화 알고리즘으로 암호화됩니다.

사업을 운영하고 고객에게 많은 송장과 제안서를 보낸다면 반드시 저희 시스템을 사용해 보시기 바랍니다. Invola는 자동 알림을 보냅니다., 송장에 대한 응답이 없는 경우 송장에 대한 고객의 반응(비싸고 긴 배송 시간 등)도 모니터링합니다. 결과적으로 지불된 청구서의 비율이 증가합니다, 또한 관리자의 성과와 자주 거부되는 이유에 대한 통계를 수집할 수 있는 기회도 있습니다.

로그인 페이지로 내장 브라우저 열기
사용자에게 권한이 부여되었는지 확인하라는 메시지가 표시됩니다.
사용자가 동의하면 브라우저는 URL이 추가된 조각(# 뒤)의 스텁 페이지로 리디렉션됩니다. 액세스 토큰
애플리케이션이 리디렉션을 가로채서 수신합니다. 액세스 토큰페이지 주소에서

이 옵션을 사용하려면 애플리케이션에서 브라우저 창을 올려야 하지만 서버 부분과 교환을 위한 추가 서버 간 호출이 필요하지 않습니다. 인증 코드~에 액세스 토큰.

예

로그인 페이지에서 브라우저를 엽니다.
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > 호스트: connect.mail.ru

사용자가 권한을 부여한 후 표준 스텁 페이지로 리디렉션이 발생합니다. Mail.Ru의 경우 이는 다음과 같습니다. connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

애플리케이션은 마지막 리디렉션을 가로채서 주소에서 가져와야 합니다. 액세스 토큰이를 사용하여 보호된 리소스에 액세스합니다.

로그인 및 비밀번호를 통한 인증

로그인 및 비밀번호를 통한 인증은 간단한 POST 요청이며 그 결과는 다음과 같습니다. 액세스 토큰. 이 체계는 새로운 것은 아니지만 일반성을 위한 표준에 포함되어 있으며 다른 인증 옵션을 사용할 수 없는 경우에만 사용하는 것이 좋습니다.

예

> POST /oauth/token HTTP/1.1 > 호스트: connect.mail.ru > 콘텐츠 유형: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru& 비밀번호= 쿼티< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
사양 설명

이전 승인 복원 중

대개, 액세스 토큰유통 기한이 제한되어 있습니다. 예를 들어, 개방형 채널을 통해 전송되는 경우 유용할 수 있습니다. 만료 후 사용자가 로그인하도록 강요하지 않으려면 액세스 토큰"그리고 위의 모든 옵션 외에도 액세스 토큰"어쩌면 다시 돌아올지도 몰라 새로고침 토큰. 당신은 그것을 사용하여 얻을 수 있습니다 액세스 토큰로그인 및 비밀번호를 사용한 인증과 유사하게 HTTP 요청을 사용합니다.

예

> POST /oauth/token HTTP/1.1 > 호스트: connect.mail.ru > 콘텐츠 유형: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < } |

OAuth 2는 애플리케이션에 사용자 계정에 대한 제한된 HTTP 액세스를 제공하는 인증 프로토콜입니다. 계정을 호스팅하고 타사 애플리케이션에 권한을 부여하며 사용자 계정에 대한 액세스 권한을 부여하는 서비스에 사용자 인증을 전달합니다. OAuth 2는 웹 애플리케이션 및 모바일 장치에 대한 인증을 제공합니다.

이 가이드에서는 OAuth 2 역할, 인증 유형, 흐름 및 OAuth 2 사용 사례를 소개합니다.

OAuth 역할

OAuth에는 네 가지 역할이 있습니다.

리소스 소유자
고객
리소스 서버
인증 서버

각 역할을 좀 더 자세히 살펴보겠습니다.

리소스 소유자: 사용자

리소스 소유자는 자신의 계정에 액세스하기 위해 애플리케이션에 인증하는 사용자입니다.

애플리케이션은 권한(즉, 특정 작업(읽기, 쓰기 등)을 수행할 수 있는 권한)을 사용하여 사용자 계정에 대한 액세스를 제한합니다.

리소스 및 인증 서버: API

리소스 서버는 보안 사용자 계정을 저장하고 인증 서버는 사용자의 자격 증명을 확인한 다음 애플리케이션 액세스 토큰을 발급합니다.

애플리케이션 개발자의 관점에서 서비스 API는 리소스 서버와 Authorization 서버의 역할을 수행한다. 다음에서는 이러한 역할을 서비스 또는 API라고 부릅니다.

클라이언트: 신청

클라이언트는 사용자 계정에 액세스하려는 애플리케이션입니다. 이를 수행하기 전에 사용자는 애플리케이션에서 승인을 받아야 하며 API는 승인을 확인해야 합니다.

프로토콜 스트림

OAuth 역할은 다음과 같이 서로 상호 작용합니다.

애플리케이션은 서비스 리소스에 대한 액세스 권한을 얻기 위해 사용자 인증을 요청합니다.
애플리케이션의 요청에 따라 사용자가 인증되면 애플리케이션은 권한을 받습니다.
애플리케이션은 인증 서버(API)에 액세스 토큰을 요청합니다.
애플리케이션이 인증되고 해당 자격 증명이 유효한 경우 권한 부여 서버(API)는 애플리케이션에 액세스 토큰을 발급합니다. 승인이 완료되었습니다.
애플리케이션은 리소스 서버(API)로부터 리소스를 요청하고 인증을 위한 액세스 토큰을 제공합니다.
액세스 토큰이 유효하면 리소스 서버(API)가 애플리케이션에 대한 리소스를 제공합니다.

애플리케이션 등록

애플리케이션에서 OAuth를 사용하려면 먼저 애플리케이션을 등록해야 합니다. 이는 서비스 웹사이트의 개발자 또는 API 섹션에 있는 등록 양식을 통해 수행되며, 여기에는 다음 정보를 제공해야 합니다.

앱 이름
신청 웹사이트;
콜백 URL 또는 리디렉션 URI(이는 인증을 통과(또는 실패)한 후 서비스가 사용자를 리디렉션하는 곳입니다. 애플리케이션의 이 부분은 인증 코드 또는 액세스 토큰을 처리합니다).

클라이언트 ID 및 비밀 키

애플리케이션을 등록한 후 서비스는 클라이언트 식별자 및 클라이언트 비밀 필드에서 찾을 수 있는 애플리케이션 자격 증명을 제공합니다. 클라이언트 ID는 서비스 API가 애플리케이션을 식별하는 데 사용하는 공개 문자열입니다. 인증 URL을 생성하는 데에도 사용됩니다. 클라이언트 시크릿을 사용하면 서비스 API가 사용자 계정에 대한 액세스를 요청할 때 애플리케이션을 인증할 수 있습니다. 이 민감한 데이터는 애플리케이션과 API 사이에 저장됩니다.

승인 권한

승인 권한은 애플리케이션이 승인을 요청하는 데 사용하는 방법과 API에서 지원하는 권한 유형에 따라 달라집니다. OAuth 2는 네 가지 유형의 권한을 정의하며 각 권한은 서로 다른 경우에 유용합니다.

인증 코드: 서버측 애플리케이션에 사용됩니다.
암시적 액세스: 웹 및 모바일 애플리케이션(사용자 장치에서 실행되는 애플리케이션)에 사용됩니다.
클라이언트에 비밀번호 제공: 안전한 것으로 알려진 애플리케이션(예: 서비스가 소유한 애플리케이션)에서 사용됩니다.
클라이언트 권한: 애플리케이션 API에 대한 액세스.

확인 코드

인증 코드는 가장 일반적인 유형의 권한으로, 소스 코드가 닫혀 있고 외부인이 클라이언트 비밀번호에 액세스할 수 없는 서버 측 애플리케이션에 최적화되어 있습니다. 이 흐름은 리디렉션 기반입니다. 즉, 애플리케이션은 사용자 에이전트(예: 사용자의 웹 브라우저)와 상호 작용할 수 있어야 하고 사용자 에이전트를 통해 라우팅되는 API 인증 코드를 받을 수 있어야 합니다.

확인 코드 스트림은 다음과 같습니다.

사용자는 확인 코드에 대한 링크를 받습니다.
사용자에게 권한이 부여되었습니다. 사용자는 링크를 클릭하여 데이터의 신뢰성을 확인합니다. 제공된 데이터가 올바르지 않으면 사용자의 승인이 거부됩니다.
애플리케이션이 인증 코드를 받습니다. 이 서비스는 확인 코드와 함께 클라이언트가 등록될 때 지정된 URI로 사용자 에이전트를 리디렉션합니다.
애플리케이션은 API에서 액세스 토큰을 요청하여 클라이언트 비밀번호를 포함한 인증 코드와 인증 데이터를 제공합니다.
인증이 유효한 경우 애플리케이션은 액세스 토큰을 받습니다.

암시적 액세스 흐름

암시적 액세스 흐름은 클라이언트 암호의 기밀성을 보장할 수 없는 모바일 애플리케이션이나 웹 애플리케이션에서 사용됩니다. 이 흐름도 리디렉션 기반이지만 사용자 에이전트는 액세스 토큰을 받은 다음 이를 애플리케이션에 전달합니다. 이렇게 하면 사용자 또는 사용자 장치의 다른 응용 프로그램에서 볼 수 있습니다. 또한 이 흐름은 애플리케이션을 인증하지 않고 URI(서비스에 등록된)를 사용하여 인증합니다.

암시적 액세스에는 새로 고침 토큰이 지원되지 않습니다.

암시적 액세스 흐름은 기본적으로 다음과 같이 작동합니다. 사용자에게 애플리케이션에 로그인하라는 메시지가 표시되면 인증 서버는 액세스 토큰을 사용자 에이전트에 전달하고 사용자 에이전트는 이를 애플리케이션에 전달합니다. 더 자세히 이 프로세스는 다음과 같습니다.

사용자는 API에서 토큰을 요청하는 암시적 액세스 링크를 받습니다.
사용자는 링크를 클릭하여 승인됩니다. 사용자가 로그인할 수 없으면 액세스가 거부됩니다.
사용자 에이전트는 액세스 토큰과 리디렉션 URI를 받습니다.
사용자 에이전트는 리디렉션 URI를 따릅니다.
애플리케이션은 액세스 토큰을 검색하는 스크립트를 보냅니다. 애플리케이션은 리디렉션 URI에서 액세스 토큰을 추출할 수 있는 스크립트가 포함된 웹 페이지를 반환합니다.
애플리케이션이 액세스 토큰을 받습니다. 승인이 완료되었습니다.

클라이언트에게 비밀번호 제공

이 유형은 사용자가 자격 증명을 애플리케이션에 직접 전달하고 이를 사용하여 액세스 토큰을 얻는다는 것을 의미합니다. 이 유형은 인증 서버에서만 지원되어야 합니다. 또한 애플리케이션을 신뢰할 수 있는 경우에만 사용해야 합니다(예: 서비스 또는 사용자 운영 체제에 속함).

사용자의 자격 증명을 받은 후 애플리케이션은 인증 서버에 액세스 토큰을 요청합니다. 자격 증명이 정확하면 인증 서버가 액세스 토큰을 제공합니다. 승인이 완료되었습니다.