[WEB][OAuth] 01. OAuth

in WEB on Web





movester를 기획하며 회원을 로컬 회원만 받을 것인지, 소셜 로그인을 허용할 것인지 고민을 했다.

소셜 로그인을 구현하기 위해 필수로 알아야할 OAuth에 대해 알아보자.

1. OAuth가 왜 필요할까?

소셜 로그인은 Movester 회원이 굳이 Movester 자체 회원가입을 하지 않고도 다른 플랫폼의 회원정보를 통해 이용하고자 할때 사용한다.

이러한 소셜 로그인을 제공하기 위해서는 필수로 3명이 필요하다.

  1. Movester
  2. User
  3. Their(google, facebook, kakao, naver)
  • Movester 는 소셜 로그인을 사용하고자 하는 애플리케이션의 주체이다.
  • User는 movester의 사용자로서 Their의 이용고객이다.
  • Thier은 소셜 로그인을 위한 인증을 제공해주는 신뢰성있는 서버이다.



앞에 세 인물은 이해가 쉽도록 이름을 지었다. OAuth에서 명명짓는 공식적인 단어는 이렇다.

  1. Movester ⇒ Client
  2. User ⇒ Resource Owner
  3. Their ⇒ Resource Server
  • 사실 Their은 엄밀히 Resource Server와 Authorization Server로 구분이 된다.
  • Resource Server는 오직 데이터만 갖고 있는 서버.
  • Authorization Server는 오직 인증만 전담하는 서버.
  • 하지만 우리는 OAuth의 동작 과정에 집중하기 위해 Resource Server로만 이야기 하겠다.
  • 또한 앞으로 쉬운 이해를 위해 정식 명칭 대신 처음 말했던 쉬운 이름으로 부르겠다.



위와 같은 세 사람이 소셜 로그인을 하기 위해 가장 떠올릴 수 있는 방법을 생각해보자.

Thier에 가입된 User의 id, pw 정보를 Movester가 알고 이를 통해 Movester가 User대신 Their의 서비스를 이용하면 되지 않을까?

매우 1차원적인 방법이다. 하지만 이는 치명적인 단점이 있다.

  1. User입장에서 Movester는 처음 보는 서비스이다. 이 서비스의 무엇을 믿고 자신의 id, pw를 맡기겠는가.
  2. 보통 대다수의 User는 서비스가 달라도 동일한 id, pw를 사용한다. 그만큼 소중한 정보인데 Movester를 뭘 믿고 이것을 내주는가!
  3. 이 소중한 정보를 Movester가 관리를 잘 못하여 유실한다면? 생각만으로 끔찍하다.
  4. Their의 입장에서도 신뢰할 수 없는 Movester에게 뭘 믿고 본인 고객의 주요 정보를 넘기는가.

위와 같은 문제점으로 인해 OAuth2가 등장하였고, 위 문제의 해결은 accessToken으로 해결되었다.

accessToken이란?

  • Their에 가입된 User의 id, pw가 아니다.
  • Their의 모든 기능을 허용하는 것이 아닌 부분적 기능만 허용한다.
  • OAuth를 통해 accessToken을 얻을 수 있다.

앞으로는 어떠한 과정을 통해 accessToken이 발급되는지를 알아보자.

2. Movester의 등록

Movester ———-register———> Their

Movester가 Their의 소셜 로그인을 사용하기 위해서는 먼저 Their과 계약을 맺어야한다.

이 계약을 통해서는 3가지 약속을 한다

  1. Client ID
  2. Client Secret
  3. Authorized redirect URIs
  • Cleint ID는 노출이 되도 되는 값이다.
  • Client Secret는 절대 노출이 되면 안되는 값이다.
  • Authorized redirect URIs는 authoized code를 전달받을 주소이다.

3. User의 승인

Their에서 제공하는 서비스는 매우 다양할 것이다. 예를 들어 Their은 A, B, C, D라는 서비스를 제공하는데 Movester는 A, B만 사용하고 싶다고 생각해보자. OAuth는 scope를 통해 이러한 최소한의 기능 승인을 가능하게 한다.

  1. Movester 가 User에게 소셜 로그인 버튼을 제공한다.

이 버튼은 자세히 살피면 다음과 같은 주소를 담고 있다.

https://resource.server/ ? client_id = 1 & scope = A, B & redirect_uri = https://client/callback

  1. User가 소셜 로그인 버튼을 클릭한다.

  2. 버튼에 담긴 https://resource.server/ 를 통해 Their은 이 User의 로그인에 관여하게된다.

    User가 로그인이 되어있지 않다면 로그인을 하게 한다.

  3. Their은 해당 버튼 주소가 가진 client_id, scope, redirect uri를 확인하여 본인이 가진 Movester에 대한 정보와 맞다면 User에게 scope 허용 여부를 전송한다.

  4. Movester가 Thier 서비스에 담긴 User의 scope를 사용할 수 있게 해도 되냐는 물음에 User가 허용한다.

  5. 허용한다면, Their은 본인의 서버에 user id : 1 scope : A, B를 추가한다.



현재까지 Thier이 가진 정보

  1. Client ID : 1
  2. Client Secret : 2
  3. Authorized redirect URIs : https://client/callback
  4. user id : 1
  5. scope : A, B



4. Their의 승인

소셜 로그인은 Moveter, User, Their 3자간 일어나는 일이므로 매우 복잡하다.

그렇기에 임시 비밀번호인 authorization code를 발급하여 관리한다.

  1. Their이 User에게 Location:https://client/callback?code:3 url 을 전송한다.
  2. 위 주소 맨 끝에 code:3 이 authorization code : 3을 의미한다.
  3. 해당 리다이렉트를 통해 User는 본인도 모르게 authorization code를 Movester에게 전해준다.
  4. 이를 통해 Movester는 이제 authorization code를 알게 됐다.

여기까지가 accessToken 발급전에 일어나는 일이었다.



5. accessToken 발급

위의 과정을 통해 이제 Movester는 User를 거치지 않고 Their에 바로 접근할 수 있는 권리를 갖게 되었다.

이제 Movester는 아래의 주소를 Their에게 전송한다.

https://resource.server/token? grant_type = authorizition_code & code = 3 & redirect_uri = https://client/callback & client_id = 1 & client_secret = 2


해당 메세지를 받은 Their은 authorization code를 통해 어떤 client인지 확인하고 그 사람이 Movester 인 것을 판단한다. 그 후 Movester의 client_id, client_secret, redirect_uri를 통해 정확한 확인을 하고 일치한다면 인증이 완료된다!

인증을 완료하였으니 이제 authorization code는 필요가 없어졌다. Movester와 Their모두 authorization code를 지운다.

Their은 accessToken : 4를 발급하여 이 정보를 Movester에게 전해준다.

앞으로 Their은 accessToken : 4를 통해 accessToken : 4를 가진 사람에게 userid를 가진 사람의 scope를 이용할 수 있는 권한을 허용하게 된다.

6. API 호출

  • API란 Their이 Movester에게 우리의 서비스를 이렇게 저렇게 이용하라고 적어놓은 설명서이다.
  • Application Programming Interface
  • Their의 각 도큐먼트를 통해 API 의 구체적인 사용법을 알 수 있다.

7. refreshToken

Movester의 위의 1~4 과정을 통해 accessToken을 갖게 되었고 앞으로 이것을 통해 User의 지속적인 허가 없이 Their의 서비스를 사용할 수 있었다.

하지만 이러한 accessToken은 수명이 있다.

그렇다면 수명이 끝날때마다 위의 과정을 반복해야할까?

이것을 쉽게 하기 위해 refreshToken이 존재한다.

OAuth의 공식 문서인 https://tools.ietf.org/html/rfc6749#section-1.5 를 참고하자

oauth

1~6과정을 통해 OAuth의 과정을 알아보았다.

마지막으로 OAuth에 대해 정리해보자

8. OAuth 정리

  • 인증 과정에 참여한 3자가 “어떻게 하면 서로를 신뢰할 수 있을까” 로부터 시작되었다.
  • OAuth를 통해 Movester는 신뢰성있는 Their을 통해 User의 신원을 인증할 수 있다.
  • accessToken을 통해 id, pw와 비슷한 역할을 하는 고유 식별자를 얻을 수 있다.
  • 이처럼 다른 서비스와의 연합을 통해 사용자의 신원을 식별하는 연합체계를 Federated Identity라고 한다.
  • OAuth의 궁극적인 목적은 Movester가 Their의 API를 제어하는 것이다.
  • 요즘 대부분의 API는 restful 스타일로 설계되었으며, 주고 받는 데이터는 json, xml 포맷을 많이 활용한다. 추후 기회가 된다면 이에 관한 포스팅도 할 예정이다.
  • 요즘 대부분의 API는 restful 스타일로 설계되었으며, 주고 받는 데이터는 json, xml 포맷을 많이 활용한다. 추후 기회가 된다면 이에 관한 포스팅도 할 예정이다.
  • OAuth를 사용한다면 보다 사회적인 애플리케이션을 만들 수 있을 것이다.

사실 OAuth의 이러한 복잡한 과정을 모르더라도 OAuth를 사용할 수 있는 library들이 무수히 많이 등장하였다. (대표적으로 passport) 하지만 OAuth의 동작과정을 정확하게 알고 넘어감으로서, 한걸음 더 나아가는 개발자가 되어보자 ^___^