OAuth의 짧은 설명

** 본 글은 OAuth 2.0을 기준으로 작성하였습니다.

OAuth 란?

---

웹, 모바일 앱, 그리고 어플리케이션에서 권한 인증을 수행할 수 있는 단순하고 표준 방법인 Open 프로토콜이다.

간단히 예를 들어보면, 자동차에 발렛키라는게 있다. (소형차만 타는 난 처음 들었다. 헉 그런게 있었어???) 발렛키는 단어 의미 그대로 발렛 파킹(대리 주차) 할 때 주차요원에게 주는 키다. 이 발렛키는 트렁크는 열수 없고, 1km만 주행할 수 있는 등 자동차 주차에 필요한 제한적인 기능만 사용할 수 있게 하는 키라고 한다(찾아보니 역시나 고급차에 포함되어 있다). 자동차의 발렛키처럼 웹서비스나 웹서비스에서 공개해 놓은 API를 사용하기 위한 인증 수단이 필요하게 된것이다. 그 인증 수단이 OAuth인 것이다.

자동차에 발렛키가 있다면, IT에서 특정 기능에 접근하기 위한 발렛키를 사용하려고 하는데, 그 IT 발렛키를 발급받기 위한 수단이 OAuth이다. OAuth을 이용하면 특정 기능에 접근 할 수 있는 인증토큰(Access Token, 발렛키)를 발급 받을 수 있는 것이다. 그 인증 토큰는 서비스를 접근하기 위한 키로 사용된다.

OAuth의 역할들(Roles)

---

Resource Owner : 사용자

Resource Server : API 서버

Client : 서드파티 어플리케이션

Authorization Server : 인증서버

OAuth에서 권한 획득 방법

---

Authorization Code

웹 서버에서 API를 호출하는 등의 시나리오에서 Confidential Client가 사용하는 방식이다. 서버사이드 코드가 필요한 인증 방식이며 인증 과정에서 client_secret 이 필요하다.

로그인시에 페이지 URL에 response_type=code 라고 넘긴다.

Implicit

Token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식이다. Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용하면 된다. Client 증명서를 사용할 필요가 없으며 실제로 OAuth 2.0에서 가장 많이 사용되는 방식이다.

로그인시에 페이지 URL에 response_type=token 라고 넘긴다.

Resource Owner Password Credentials

이 방식은 2-legged 방식의 인증이다. Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 access token을 받아오는 방식이다. Client 를 믿을 수 없을 때에는 사용하기에 위험하기 때문에 API 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서만 사용하는 것을 추천한다.

로그인시에 API에 POST로 grant_type=password 라고 넘긴다.

Client Credentials

어플리케이션 이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다.

로그인시에 API에 POST로 grant_type=client_credentials 라고 넘긴다.

OAuth는 어떻게 작동하는가?

---

title OAuth 2.0 flow

Client->+Resource Owner: (A) Authorization Request
Resource Owner-->-Client: (B) Authorization Grant
Client->+Authorization Server: (C) Authorization Grant
Authorization Server-->-Client: (D) Access Token
Client->+Resource Server: (E) Access Token
Resource Server-->-Client: (F) Protected Resource

     

위 플로우차트는 4개의 역할들 간 절차를 보여주며 각각의 단계는 다음과 같다.

(A)  Client는 Resource Owner에게 권한은 요청한다. 권한 요청은 Resouce owner에게 위와 같이 직접 전달 될수도 있으며, 또는 간접적으로 중개인 역활을 하는 인증 서버를 통해 간접적으로 전달 될수도 있다.

(B) Client는 Resource Owner의 권한을 나타내는 증명서와 같은 권한 인증서를 얻는다. 이 권한 인증 방식은 OAuth 명세에 정의된 4가지 권한 인증 방식 중 하나이거나, 또는 확장형 권한 인증 방식(Extension grant type)을 사용한다.(이에 대한 자세한 설명을 보고자 하면, [링크]를 눌러서, 4절의 내용을 보면 된다.) 인증 권한 타입은 권한 인증한 클라이언트, 그리고 인증 서버가 지원하는 타입에 따라 다르다.

(C) Client는 Authorization Server에  클라이언트 인증과 (B)에서 획득한 권한 인증서을 이용해 Access token을 요청한다.

(D) Authorization Server는 클라이언트를 인증하고, 권한 인증서가 유효한지 검증한다. 그리고 모든게 유효하면 Access Token을 발행한다.

(E) Client는 Resource Server에 Access Token을 넘겨, 제한적으로 사용할 수 있는 자원을 요청한다.

(F) Resource Server는 Access Token 유효한지 검증하고, 유효한 경우 제한적으로 사용할 수 있는 자원을 넘겨준다.

여기서 Client가 Resource Owner로 부터 권한 인증서를 얻어오는 방법은 Authorization Server를 중개인으로 둬서,  Authorization Sever를 통해 Resource Owner로 부터 권한 인증서를 얻어오는 방법을 추천하고 있다. 

다음에는 직접 오픈 소스를 이용해 OAuth를 간단한 예제를 구현해 보겠다. 조금 더 한글로 자세히 정리된 곳을 보고 싶다면, 아래 참조 사이트의 [링크]를 따라가 보면 된다.

참조사이트

---

http://tools.ietf.org/html/rfc6749

http://en.wikipedia.org/wiki/OAuth

http://earlybird.kr/1584