취업을 하며 그 대표님이 이 구조에 대해서 여기 사이트를 보며 알아놓으면 좋다고 하길래 알아놓기 위해 이렇게 기록으로 남긴다. 사이트 보고 나서 너무 무서워서 쓸 수 밖에 없었다.. 한번 봤는데 어질어질한 사이트..

아직 호칭도 어색한 쌩신입니다..

OAuth 2.0이란

인증 및 인가 프로토콜로서, 인터넷에서 클라이언트 애플리케이션이 사용자 리소스에 대한 접근 권한을 안전하게 위임할 수 있도록 할 수 있는 프레임워크, 클라이언트-서버 모델을 기반으로 한다.

다양하게 정의되고 있다.

• Wikipedia
  다른 웹사이트 상에 있는 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 수단으로 사용되는, 접근 위임을 위한 개방형 표준
• RFC
  애플리케이션이 특정 수준으로 제한된 HTTP service를 이용할 수 있게 하는 표준으로, 승인 절차를 거쳐 유저의 정보에 대신 접근 가능하게 한다.

즉, 인증과 권한을 얻기위해 사용하는 툴 같은 것이다.

나오게 된 계기

인터넷에서의 신뢰성과 보안성을 강화하기 위한 필요성에서 비롯됐다. F8부터!

OAuth가 나오기 전에는 사용자가 다른 웹 서비스와 상호 작용할 때 자신의 인증 정보, 즉 사용자 이름과 비밀번호를 해당 서비스와 공유해야 했다.
이러면 문제점이 여러 웹 사이트에 가입하고 로그인하기 위해서는 각 웹 사이트에 대해 개인 정보를 줘 별도의 계정을 생성하고 관리해야 했다. 그러면서 사용자에게 번거로움을 초래했을 뿐만 아니라, 보안상의 위험도 증가시켰다.

OAuth는 이러한 문제를 해결하기 위해 등장했다.
OAuth의 의의는 사용자가 자신의 인증 정보를 제 3자 서비스에 직접 공유하지 않고도 다른 애플리케이션이나 서비스가 사용자의 리소스에 접근할 수 있도록 하는 것이다.
OAuth를 사용하면 사용자는 신뢰할 수 있는 인증 서비스를 통해 접근 권한을 부여할 수 있고, 인증 정보를 공유하지 않고도 다른 애플리케이션이나 서비스가 사용자의 데이터에 접근할 수 있다.

즉, 리소스를 전달하는 서버와 인증을 관리하는 서버를 따로 두고, 인증 전용 서버를 제 3자든 어디든 보안이 높은 서버에서 등록된 하나의 계정을 가지고 권한을 준다.
이는 여러 개 계정을 등록하거나 인증 정보에 대한 유출 및 불안감을 해소해준다.

Protocol Flow

일단 기본적인 권한 토큰인 액세스 토큰이 있을 때가 문서 첫번째로 기술돼있기에 간단하게 과정 설명하고 넘어가겠다.

OAuth 2.0의 프로토콜 플로우는 Figure 1에서 설명된 네 가지 역할 간의 상호 작용을 나타내며, 다음과 같은 단계로 구성된다.
출처 : The OAuth 2.0 Authorization Framework

(A) 클라이언트는 리소스 소유자에게 인가를 요청한다. 인가 요청은 리소스 소유자에게 직접적으로 할 수 있다(그림에서 보여지는 대로). 또는 중개자로서의 인증 서버를 통해 간접적으로 요청할 수 있다.
(B) 클라이언트는 인가 승인(Authorization Grant)을 받는다. 인가 승인은 리소스 소유자의 인가를 나타내는 자격증이다.
이는 이 명세서에서 정의된 네 가지 승인 유형 또는 확장 승인 유형 중 하나를 사용하여 표현된다. 인가 승인 유형은 클라이언트가 인가를 요청하는 방법 및 인증 서버에서 지원하는 유형에 따라 달라진다.

(C) 클라이언트는 인증 서버에 인증하고 인가 승인을 제시하여 액세스 토큰을 요청한다.
(D) 인증 서버는 클라이언트를 인증하고 인가 승인을 검증하며, 유효하다면 액세스 토큰을 발급한다.

(E) 클라이언트는 액세스 토큰을 제시하여 리소스 서버로부터 보호된 리소스를 요청하고 인증한다.
(F) 리소스 서버는 액세스 토큰을 검증하고, 유효하다면 요청된 리소스를 제공한다.

즉, 클라이언트는 리소스 소유자로부터 인가를 받아 액세스 토큰을 요청하고, 이를 통해 리소스 서버로부터 보호된 리소스를 인증 서버에 요청하며 인가가 확인되면 데이터를 제공한다.

OAuth 2.0 With Refresh Token

1.5. Refresh Token을 번역하여 설명하겠다.

출처 : The OAuth 2.0 Authorization Framework

(A) 클라이언트는 인증 서버에 인증하여 인가 승인을 제시함으로써 액세스 토큰을 요청한다.
(B) 인증 서버는 클라이언트를 인증하고 인가 승인을 유효성 검사하고, 유효하다면 액세스 토큰과 리프레쉬 토큰을 발급한다.

(C) 클라이언트는 액세스 토큰을 제시하여 보호된 리소스 요청을 리소스 서버에 보낸다.
(D) 리소스 서버는 액세스 토큰을 검증하고 유효하다면 요청을 처리한다.
(E) 단계 (C)과 (D)는 액세스 토큰의 만료까지 반복된다. 클라이언트가 액세스 토큰이 만료되었음을 인지하면 단계 (G)로 건너뛰고, 그렇지 않으면 다른 보호된 리소스 요청을 생성한다.
(F) 액세스 토큰이 유효하지 않기 때문에 리소스 서버는 잘못된 토큰 오류를 반환한다.

(G) 클라이언트는 인증 서버에 인증하여 리프레쉬 토큰을 제시함으로써 새로운 액세스 토큰을 요청한다. 클라이언트의 인증 요구사항은 클라이언트 유형과 인증 서버의 정책에 따라 달라진다.
(H) 인증 서버는 클라이언트를 인증하고 리프레쉬 토큰을 유효성 검사하며, 유효하다면 새로운 액세스 토큰(그리고 선택적으로 새로운 리프레쉬 토큰)을 발급한다.

위 이미지와 과정을 함께 보면 이해가 빠를 것이다. 리프레쉬가 들어갔다고 해서 어려워지는 건 아니지만 G, H 같은 과정들이 추가된다.

리프레쉬 토큰을 추가함으로써 인증 절차를 더 밟게 해 리소스 보호를 해준다. 그리고 모던 웹 개발에서도 이 방식을 많이 채택하고 있다.

Authorization Code Grant

Protocol Flow에서 '네 가지 승인 유형 또는 확장 승인 유형 중 하나를 사용하여 표현'이라고 얘기했다. 공식문서에서는 Section 4부터 기술하고 있다.

1. 인가 코드(Authorization Code)
2. 암시적(Implicit)
3. 리소스 소유자 인증코드 증명(Resource Owner Password Credentials)
4. 클라이언트 자격 증명(Client Credentials)

이렇게 4가지가 있는데 4가지 다 기술하기엔 글 목적에 좀 멀어지는 게 있어 가장 유명한 1번 Authorization Code를 기술하겠다.

이 승인 유형은 클라이언트가 액세스 토큰을 얻기 위해 인증 서버에 인가를 요청할 때 사용된다.

출처 : Authorization Code Grant

(A) 클라이언트는 인증 서버에게 Authorization Endpoint로 리소스 소유자의 사용자 에이전트를 이동시키는 것으로 플로우를 시작한다. 클라이언트는 클라이언트 식별자, 요청된 스코프, 로컬 상태 및 액세스가 허용되면 인증 서버가 사용자 에이전트를 리디렉션할 리디렉션 URI를 포함한다.

(B) 인증 서버는 리소스 소유자(사용자 에이전트를 통해)를 인증하고 리소스 소유자가 클라이언트의 액세스 요청을 승인하거나 거부하는지 확인한다.

(C) 리소스 소유자가 액세스를 승인하면 인증 서버는 이전에 제공된 리디렉션 URI를 사용하여 사용자 에이전트를 클라이언트로 리디렉션한다. 리디렉션 URI에는 인가 코드와 클라이언트가 이전에 제공한 로컬 상태가 포함된다.

(D) 클라이언트는 이전 단계에서 받은 인가 코드를 포함하여 인증 서버의 토큰 엔드포인트에 액세스 토큰을 요청한다. 요청을 할 때, 클라이언트는 인증 서버와 함께 인증한다. 클라이언트는 인가 코드를 검증하기 위해 인가 코드를 얻는 데 사용된 리디렉션 URI를 포함한다.

(E) 인증 서버는 클라이언트를 인증하고 인가 코드의 유효성을 검사하며, 받은 리디렉션 URI가 단계 (C)에서 클라이언트를 리디렉션하는 데 사용된 URI와 일치하는지 확인한다. 유효하다면, 인증 서버는 액세스 토큰과 선택적으로 리프레시 토큰을 응답으로 돌려준다.

즉, 인가를 주는 방식 중 인가 코드를 줘서 권한을 주는 방식인 것이다. 그냥 요청하는 것이 아닌 인가 코드를 검사해 제대로 된 사용자가 주는 요청인지 확인하고, 권한인 토큰을 주는지 안주는지에 대해 미리 판단한다.