OAuth 2.0(작성 중)

개요

Token based Authentication 관련 구현에 관심이 있어 공식문서와 여러 인터넷 예제를 참고하여 정리한 글입니다.

Introduction

Roles

OAuth에는 3가지 역할이 있다.

• Client는 우리가 현재 제공하고 있는 Third party service이다.
• Resource Owner는 우리의 서비스를 제공받는 사용자이다.
• Resource Server는 Client에게 Resource를 제공해줄 대상이며 구글, 페이스북 등이 될 수 있다.
• Authorization Server는 RO가 인증 시도와 클라이언트에게 토큰을 발급해주는 서버이다. 보통 RO와 같이 사용되기 때문에 이번 포스트에서는 구분을 두지 않으려 한다.

Protocol Flow

대략적인 프로토콜 개요는 아래와 같다.

• (A) 클라이언트는 RO에게 인증을 요청한다 AO를 통해서 요청할 수도 있고 직접 요청할 수도 있다.
• (B) 클라이언트는 authorization grant를 전달 받는다. 이는 클라이언트가 인증되었음을 나타낸다. authorization grant의 타입은 클라이언트의 요청과 AO가 지원하는 타입에 의존한다.
• (C) 클라이언트는 인증과 함께 엑세스 토큰을 요청하고 authorization grant되었음을 알린다.
• (D) 서버는 authorization grant을 확인하고 클라이언트를 인증한다. 인증이 완료되면 엑세스 토큰을 발급한다.
• (E) 클라이언트는 엑세스 토큰을 통해 민감정보를 요청할 수 있다.
• (F) 서버는 토큰의 유효성 검사를 진행 후 응답을 보낸다.

Access Token

액세스 토큰은 사용자 민감 정보의 접근할 수 있는 일종의 자격이다. 클라이언트가 발급하며, authorization 즉, 인증되었음을 나타내는 문자열이다. 대개는 클라이언트는 이 토큰을 인식할 수 없도록 한다. 토큰은 RO가 제공한 특정 스코프를 가지고 생성되며, 만료시간을 가진다. 만료시간은 RS, AS에 의해 강제된다.

JWT를 이전에 사용해 보았기에 특정 문자를 인식할 수 있음은 쉽게 이해할 수 있다.

엑세스 토큰은 다양한 응용방식이 있는데 rfc6750에서 직접 살펴볼 수 있다. 이는 추후 포스팅에서 다시 다루도록 하겠다.

Refresh token

리프레쉬 토큰은 엑세스 토큰을 얻기 위한 일족의 자격이라고 볼 수 있다. 이는 AO에 의해 클라이언트가 발급하며 엑세스 토큰이 파기되거나 유효하지 않을 경우 새로운 엑세스 토큰을 얻기 위해 사용된다. 리프레쉬 토큰은 AO에서 엑세스 토큰을 발급할 때 함께 동봉되며 이는 AO의 재량에 따른 선택적 사항이다.

엑세스토큰과 달리 리프레쉬 토큰은 리소스 서버에 전송되지 않는다.

• (A) 클라이언트는 권한 부여 서버에 인증하고 권한 부여를 제시하여 엑세스 토큰을 요청한다
• (B) 인증 서버가 권한 부여와 클라이언트의 유효성을 검사한다. 유효할 경우 리프레쉬 토큰과 엑세스 토큰을 보낸다.
• (C) 클라이언트가 엑세스 토큰을 이용하여 서버에게 데이터를 요청한다.
• (D) 토큰이 유효할 경우 데이터를 보낸다.
• (E) 엑세스 토큰이 파기되기 전까지 (C)와 (D)를 반복한다. 만약 토큰이 파기된 것을 안다면 앞에 과정을 생략하고 (G)로간다.
• (F) 토큰이 유효하지 않을 경우 서버는 invalid token error를 보낸다.
• (G) 클라이언트가 새로운 액세스 토큰을 발급 받기 위해 서버에 인증 후 리프레쉬 토큰을 제시한다.
• (H) 인증 서버가 클라이언트를 인증하고 리프레쉬 토큰의 유효성을 검사한다. 만약 유효할 경우 새로운 엑세스 토큰을 발급한다.

Protocol Endpoints

인증 프로세스는 두 개의 인증 서버 엔드포인트로 운용된다.

• Authorization endpoint: 클라이언트가 user-agent 리다이렉션을 통해 RO로부터 권한을 얻기 위해 사용한다.
• Token Endpoint: 클라이언트가 엑세스 토큰에 대한 authorization grant 교환을 위해 사용하며, 일반적으로 클라이언트 authentication 사용한다.

클라이언트 또한 한 개의 엔드포인트를 갖는다.

• Redirection endpoint - 인증 서버가 resource owner user-agent를 통해 클라이언트에게 인증자격(authorization credentials)을 포함한 응답을 보내기 위해 사용한다.

Authorization Code Grant

RO가 승인했다 해서 access token을 바로 발급하지 않고 RS와 상호협의를 위해 거쳐야하는 단계이다.

;

• (A): 이는 클라이언트가 RO의 user-agent를 Authorization endpoint가리키며 시작한다. 클라이언트는 식별자, 요청 범위 로컬상태 및 AO가 권한을 부여(또는 거부)한 후 user-agent를 다시 보낼 리디렉션 URI를 포함한다.
• (B): AS는 RO를 인증하며(user-agent를 통해서) 클라이언트의 엑세스 요청에 대한 권한 부여 혹은 거부를 결정한다.
• (C): RO의 권한 부여가 허용되면, AO는 이전에 받았던(클라이언트 등록 혹은 권한 요청에서) 리디렉션 URI를 통해 user-agent를 리다이렉트 한다. 리디렉션 URI에는 이전에 클라이언트가 제공한 인증 코드(Autorization Code)와 모든 로컬 상태가 포함되어 있다.
• (D): 클라이언트는 이전 단계에서 받았던 인증 코드를 포함하여 AO의 Token Endpoint에 엑세스 토큰을 요청한다. 요청이 진행될 때 클라이언트는 AO로부터 인증한다. 클라이언트는 verification을 위한 인증코드를 얻기 위해 리디렉션 URI를 포함한다.
• (E): AO가 클라이언트를 인증하고 인증코드를 검증한다. 그리고 받은 URI가 단계(C)에서 클라이언트를 리다이렉트하는 데 사용된 URI와 일치하는지 확인한다.

Refernce

• https://opentutorials.org/course/3405
• https://tools.ietf.org/html/rfc6749#section-4.1