OAuth 2.0 개념 (Workflow & Authorization Grant)

OAuth 란?

인증을 위한 개방형 표준 프로토콜

기존 클라이언트 - 서버 인증 모델에서 client는 resource owner의 자격 증명을 사용하여 서버로 인증하여 서버에 액세스 제한 리소스(보호된 리소스)를 요청합니다.
제한된 리소스에 대한 third-party applications 액세스를 제공하기 위해 resource owner는 해당 자격 증명을 third-party와 공유합니다.

간단한 예를 들자면, 간편로그인으로 Naver, Google, Kakao 등을 이용하는 것도 OAuth2 프로토콜 기반으로 사용자 인증 기능을 각 회사에서 제공하는 것입니다.

 

OAuth 역할 : 4가지 역할의 정의

resource owner

• 보호된 리소스에 대한 엑세스 권한을 부여할 수 있는 엔터티, 최종 사용자

resource server

• 엑세스 토큰을 사용하여 보호된 리소스 요청을 수락하고 응답할 수 있는 보호된 리소스를 호스팅하는 서버

client

• 사용자를 대신하여 권한을 부여하여 보호 자원을 요청하는 프로그램

authorization server

• 사용자를 성공적으로 인증하고 권한을 얻은 후, 클라이언트에 엑세스 토큰을 발급하는 서버

 

OAuth 2.0 주요 용어

Authentication

• 인증, 접근 자격이 있는지 검증하는 단계

Authorization

• 인가, 자원에 접근할 권한을 부여하는 것으로, 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 Client에게 부여

Access Token

• 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용
• 만료기간이 있는 Token

Refresh Token

• Access Token 만료시 이를 갱신하기 위한 용도로 사용되는 Token
• 일반적으로 Access Token보다 긴 만료 기간

 

OAuth 2.0 인증과정

출처 : https://developers.payco.com/guide

OAuth2.0 프로세스

출처 : https://developers.payco.com/guide

1~5 단계는 Authorization Code 발급 요청 URL을 통해 진행할 수 있습니다.
7~8 단계는 서비스에서 callback URL 을 통해 전달받은 Authorization Code를 사용하여 Access Token 요청 API를 통해 진행할 수 있습니다.
8 단계에서 발급받은 Access Token은 서비스에서 자체적으로 저장, 관리해야 합니다.
10~11 사용자의 서비스 요청 시 회원정보가 필요하다면 Access Token을 사용해 API를 호출할 수 있습니다.

 

---

Obtaining Authorization

액세스 토큰을 요청하기 위해 클라이언트는 리소스 소유자로부터 승인을 받습니다. 권한 부여는 클라이언트가 액세스 토큰을 요청하기 위해 사용하는 권한 부여의 형태로 표현됩니다. OAuth는 아래의 4가지 유형으로 정의합니다. 또한 추가 부여 유형을 정의하기 위한 확장 메커니즘을 제공합니다.

 

 

Authorization Code Grant | 권한 부여 승인 코드 방식

Authorization Code Grant은 많이 쓰이고 기본이 되는 방식, Access Token과 Refresh Token을 모두 가져오는 데 사용되며 클라이언트에 최적화되어 있습니다. redirection-based flow이므로 클라이언트는 사용자의 user-agent(일반적으로 웹 브라우저)와 상호 작용할 수 있어야 하며 authorization server에서 수신 요청을 수신할 수 있어야 합니다.

아래는 Authorization Code flow 입니다.

1. 클라이언트는 사용자에게 authorization endpoint로 클라이언트 식별자, 요청 범위(얻고자 하는 데이터), 로컬 상태 및 권한 부여에 대해 허용(또는 거부)하면 redirection URI 와 함께 반환
2. authorization server는 사용자를 인증하고 사용자가 클라이언트의 엑세스 요청을 승인 또는 거부 여부를 설정
3. 사용자가 엑세스 권한을 부여한다고 가정하면 authorization server는 이전에 제공된 redirection URI를 사용하여 user-agent를 클라이언트로 다시 redirection(재요청 또는 클라이언트 등록 중)
4. 클라이언트는 이전 단계에서 받은 인증 코드를 포함, authorization server의 authorization endpoint에서 엑세스 토큰을 요청합니다. 요청할 때 클라이언트는 authorization server로 인증합니다. 클라이언트는 확인을 위한 인증 코드를 얻는 데 사용되는 redirection URI를 포함합니다.
5. authorization server는 클라이언트를 인증하고 권한 부여 코드를 검증하며 수신된 redirection URI가 (3)에서 사용된 URI와 일치하는지 확인, 유효한 경우 authorization server는 Access Token과 Refresh Token(선택)을 제공

authorization endpoint : OAuth 권한 부여 요청을 하는 데 사용하는 URL

위와 같은 내용이지만, 참고를 통해서 쉽게 이해하였습니다.

 

Implicit Grant | 암묵적 승인 방식

자격증명을 안전하게 저장하기 힘든 클라이언트(javascript와 같은)에게 최적화된 방식

리디렉션 기반으로 클라이언트는 사용자의 user-agent와 상호작용할 수 있어야 하고 authorization server로부터 들어오는 요청을 수신할 수 있어야 합니다.

 

 

Resource Owner Password Credentials Grant | 자원 소유자 자격증명 승인 방식

간단하게 username, password로 Access Token을 받는 방식

자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용하는 방식, Refresh Token 사용 가능

 

 

Client Credentials Grant | 클라이언트 자격증명 승인 방식

클라이언트 자격증명으로만 Access Token을 획득하는 방식

자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되며, Refresh Token 사용 불가

OAuth2.0 : 참고사이트

참고블로그