OAuth 알아보기

[OAuth란 무엇인가?]

Wiki에서 이야기 하는 OAuth는 아래와 같다. (https://ko.wikipedia.org/wiki/OAuth)

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.[1] 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존,[2] 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.

위 내용을 사례와 함께 정리해 보자.

친구와 소통하는 웹서비스가 있다고 가정하자. 이 웹서비스는 사용자의 친구들의 정보를 Facebook으로부터 전달받아 활용하고 있다. 위와 같이 구성된 웹서비스를 사용자가 사용하고자 한다면 두번의 인증이 필요하다. (친구와 소통을 하는 웹서비스와 Facebook의 인증) 친구 소통 웹서비스 인증은 일반적으로 생각하는 로그인 절차를 떠올리면 된다. 그렇다면 내부에 사용되고 있는 Facebook의 인증은 어떻게 해야 할까? 사용자가 친구 소통 웹서비스에 Facebook ID/PW를 입력하면 웹서비스는 그것을 다시 Facebook에 전달하여 인증 절차를 진행할 수 있을 것이다. 하지만 사용자는 Facebook ID/PW를 난생 처음 본 친구 소통 웹서비스에 입력하는 것을 꺼려 한다. 그 이유는 친구 소통 웹서비스를 신뢰하지 못하기 때문이다. 그렇다면 Facebook ID와 PW를 친구 소통 웹서비스에 입력하지 않고 Facebook 인증을 받을 수 있는 방법은 없을까? 이것을 가능하게 해준 것이 바로 OAuth이다. 사용자는 Facebook ID와 PW를 친구 소통 웹서비스에 입력하지 않고 Facebook에 직접 인증 절차를 진행한다. 그리고 친구 소통 웹서비스는 Facebook에서 진행된 인증 결과물(Token)을 바탕으로 서비스를 제공 받는다.

*한줄 요약 : 제 3의 앱이 자원의 소유자인 서비스 이용자를 대신하여 서비스를 요청할 수 있도록 자원 접근 권한을 위임하는 방법

[OAuth의 탄생 비화]

OAuth 1.0은 2007년에 나왔으며 이후 보안 문제를 해결한 OAuth1.0 revisionA가 2008년에 세상에 나왔다.

OAuth의 시작은 2006년 트위터 개발자와 소셜 북마크 서비스인 Gnolia의 개발자가 만나 인증 방식을 논의하며 시작되었다. 그들은 논의중 API 접근 위임에 대한 표준이 없다는 사실을 알고 2007년 4월 인터넷에 OAuth 논의체를 만든 뒤 OAuth 드래프트 제안서를 만들어 공유 하였다. 그 뒤 이 활동을 지지하는 사람들이 생기면서 2008년 IETF모임(73회, 미네소타에서 개최)에서 OAuth가 IETF 표준안으로 관리되어야 하는 가에 대한 논의를 하였으며 이어 2010년에 OAuth1.0 프로토콜 표준안이 RFC5849로 발표 되었다. OAuth의 탄생 이전에도 다른 애플리케이션에 아이디나 비밀번호가 오픈되지 않으면서 인증을 하는 API 접근 위임이 가능한 여러 인증 방법이 있었다고 한다.

[OAuth 2.0 알아보기]

OAuth 사이트 :  https://oauth.net/2/

스펙 문서는 RFC 6749에서 확인 가능. (https://tools.ietf.org/html/rfc6749)

OAuth2.0의 권한 흐름을 간략히 설명하면 아래와 같다. 

[출처 : http://blog.weirdx.io/post/39955]

1. Customer가 Client에 접근하여 서비스를 사용하고자 한다. 
2. Client는 Resource Owner에게 인증 코드를 요청한다. 
3. Resource Owner가 발행한 인증 코드로 Client는 Authorization Server에 Access Token을 요청한다. 
4. 발급 받은 Access Token으로 Client는 Resource Server에 요청한다.

<용어 정리> -Customer : 사용자 -Client : 사용자에게 서비스 제공하는 서비스 and OAuth로 API Service에 인증과 인가를 해야함.

위 내용은 아주 심플하게 OAuth 2.0의 권한 부여 흐름을 살펴본 것이다.

조금 더 구체적인 사례로 마이크로소프트에서 사용하는 방식을 함께 살펴보자.

[출처 : https://docs.microsoft.com/ko-kr/azure/active-directory/develop/v1-protocols-oauth-code]

위 내용을 보면 조금더 구체적으로 권한을 부여 받는 흐름을 알 수 있다.  

권한 부여시 요청하는 Parameter정보와 스펙을 알고 싶다면 위 출처에 작성된 URL에 들어가서 참고하면 쉽게 알 수 있을 것이다. 

[Refresh Token이란 무엇인가?]

Access Token은 일정 시간이 지나면 만료된다.

즉 일정 시간이 지난 후 발급 받은 Access Token으로는 서비스를 제공받을 수 없다.

이와 같은 상황에서 Refresh Token을 사용하게 된다.

(Refresh Token은 Access Token 발급시 함께 전달된다.)

Access Token이 만료되는 시점에 Refresh Token을 통해 다시 유효한 Access Token을 받을 수 있다.

(Access Token을 다시 생성시 옵션으로 Refresh Token도 다시 받을 수 있다.)

[OAuth2.0의 특징]

1. OAuth 1.0의 한계
   OAuth1.0은 웹 애플리케이션이 아닌 애플리케이션에서는 사용이 어렵다. 
   또한 절차가 복잡하여 OAuth 구현 라이브러리를 만드는 것도 어렵고 OAuth 인증을 제공해주는 서비스 측에서도 연산에 부담이 발생하는 단점이 있었다. 
   OAuth2.0은 이와 같은 단점을 극복하고자 나왔다. 하지만 1.0과 호환이 되지는 않는다.
2. OAuth 2.0 개선 사항
   1. 웹 어플리케이션 이외에 애플리케이션 지원을 강화 하였다. 
   2. 별도 암호화가 필요없이 HTTPS를 사용하고 있다. 
   3. HMAC을 사용하지 않는다. (HMAC은 REST API 무결성을 보장하기 위한 방법 https://hanee24.github.io/2018/04/22/hmac-authentication/)
   4.  Signature 단순화 및 URL 인코딩을 하지 않음.
      (*signature는 OAuth1.0에서 OAuth 인증 정보를 암호화하고 인코딩하여 서명하는 값이다. OAuth인증 정보는 매개변수 중에서 oauth_signature를 제외한 나머지 매개변수와 HTTP 요청 방식을 문자열로 조합한 값이다. 암호화 방식은 oauth_signature_method라는 매개변수에 정의된 방식을 따르고 대부분 HMAC-SHA1, HMAC-MD5등을 사용한다.)
   5.  Access Token에 Life-Time을 지정할 수 있도록 함. (OAuth 1.0에서는 지원하지 않았음)