[OAuth] 생활코딩 - OAuth 2.0

[210515]

생활코딩 - OAuth 2.0

1. 수업 소개

수업 소개

사용자가 가입된 서비스의 API에 접근하기 위해서는 사용자로부터 권한을 위임 받아야 합니다. 이 때 사용자의 패스워드 없이도 권한을 위임 받을 수 있는 방법이 필요합니다. 이를 위해서 고안된 기술이 OAuth입니다. 오늘날 많은 API들이 OAuth를 통해서 상호 연동을 지원하고 있습니다.

수업 대상

구글, 페이스북과 같은 서비스의 API에 사용자 대신에 접근하고 싶은 분들을 위한 수업입니다. 또 아래 그림과 같이 다른 서비스로 로그인 하기 기능을 구현하는데도 필수적으로 필요한 기능입니다.

OAuth란?

• Mine : 나의 서비스

• User : 사용자 (나의 서비스를 사용하는 사람들)

• Their : 그들의 서비스 (구글, 페이스북, 트위터 ... )

사용자가 나의 서비스를 통해 그들의 서비스를 이용할 수 있게 하는 기술.

(ex 사용자가 내 서비스를 통해 구글 캘린더에 일정을 기록할 수 있게 함)

그러려면 그들의 서비스의 사용자 ID, PW를 알아야 한다. - 매우 간단하고 강력한 방법.

하지만 그만큼 위험한 방법이다.

사용자, 그들의 서비스 - 어떻게 나의 서비스를 믿고 그들의 서비스의 ID,PW를 줄 것인가?

→ OAuth는 이러한 문제를 해결해 준다.

• Their 그들의 서비스 : 사용자의 요청에 의해 accessTocken을 발급한다.

  • 사용자의 ID, PW를 넘겨주지 않아도 된다.
  • 그들의 서비스의 모든 기능이 아닌, 나의 서비스에 필요한 필수적인 부분만 사용하도록 허용할 수 있다.

• Mine 나의 서비스 : 그들의 서비스가 발급한 accessTocken을 획득한 다음, 그 accessTocken을 통해 그들의 서비스에 접근할 수 있다.

  • 그들의 서비스에 접근해 CRUD를 할 수 있다.

  • 사용자의 ID,PW 관리 부담이 없다.

  • 나의 서비스에 로그인 할 때에도 ID, PW를 보관하지 않고 그들의 서비스의 accessTocken을 통해 사용자를 식별할 수 있다.

    • Login with Google (구글 아이디로 로그인) 과 같은 기능 구현 가능.

2. 역할 (Role)

OAuth에 등장하는 3자에 대한 역할과 용어를 알아보는 시간입니다.

OAuth 의 세 주체

• Resource Owner (= User)

  • 우리의 사용자
  • 자원의 소유자

• Client (= Mine)

  • 우리가 만든 서비스 (ex. opentutorials.org)
  • Resource Server로부터 자원을 요청하는 입장이기 때문에 Client라고 한다.

• Resource Server (= Their)

  • User가 사용하는 또 다른 서비스
  • User는 Their에 회원가입이 되어 있는 상태 (ex. Google, Facebook, Twitter)
  • '우리가 제어하고 싶은 자원을 가지고 있는 서버'라는 의미에서 Resource Server라고 한다.
    • Resource 데이터를 가지고 있는 서버를 말함

• Authorization Server (=Their)

  • Their의 서버 중 인증과 관련 처리를 전담하는 서버를 말함.

이 강의에서는 쉬운 설명을 위해 Authorization Server까지 합쳐서 Resource Server로 설명한다.

3. 등록 register

OAuth를 이용해서 Resource Server에 접속하기 위해서는 우선 Resource Server에 등록하는 과정이 필요합니다. 이를 위한 방법을 소개합니다.

Resource Server의 데이터를 이용하기 위해서는, Resource Server에 승인을 먼저 받아 두어야 한다. 이를 '등록'이라고 한다.

(Resource Server마다 구체적인 방식은 다르다)

등록의 3요소

• Client ID
  • 우리가 만든 애플리케이션의 식별자(id)
• Client Secret
  • Client ID에 대한 비밀번호.
  • 절대로 외부에 노출되어서는 안 된다!!
• Authorized redirect URIs (redirect URL)
  • Resource Server가 권한을 부여하는 과정에서 우리가 Authorize Code를 전달해 준다.
  • 이 Authorize Code를 전달받는 URI가 Authorized redirect URIs이다.
  • Client가 Authorized redirect URIs 외의 주소로 요청하면 Resource Server는 해당 요청을 무시한다.
  • ❗ Client는 Authorized redirect URIs로 등록할 페이지를 미리 구현해 두어야 한다.

등록 절차 후의 상태

• Resource Server(their)는 Client의 Client ID, Client Secret, redirect URL을 알게 된다.
• Client(Mine)은 Client ID, Client Secret 을 부여받게 된다.

4. Resource Owner의 승인

OAuth의 첫번째 절차는 Resource Owner가 Resource Server에게 Client의 접근을 승인한다는 것을 알려줘야 합니다. 이 과정을 알아보겠습니다.

등록 후의 상태

• Resource Server(their)는 Client의 Client ID, Client Secret, redirect URL을 알게 된다.
• Client(Mine)은 Client ID, Client Secret 을 부여받게 된다.

등록 후에는 인증을 받는 과정이 필요하다.

우리는 Resource Server가 제공하는 기능들(A,B,C,D) 중 필요한 기능(B,C)만을 승인받아 사용하면 된다.

Resource Owner(User)가 "Login with Google"과 같은 버튼을 누르는 것은 곧, Resource Owner가 해당 기능을 사용하는 것에 동의함을 의미한다.

"Login with Google"과 같은 버튼은 아래와 같은 주소로 연결된다.

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

• Client ID
• scope
  • 사용하고자 하는 기능들
• Redirect URL

실제 버튼의 URL은 "URLDECODE.ORG"와 같은 사이트에서 해독해 내용을 확인할 수 있다.

승인 절차

1. Resource Owner가 Resource Server로 접속한다

2. Resource Server는 Resource Owner가 로그인 상태인지 확인한다.

   1. 로그인이 되어 있으면
   2. 로그인이 되어 있지 않으면 로그인을 요청한다.

3. 위와 같은 주소를 통해 Resource Owner가 로그인한다

4. Resource Server는 요청받은 주소에 포함된 Client ID값이 있는지, Client ID에 등록된 Redirect URL과 일치하는지 확인한다.

   • 만약 다르면 해당 요청을 무시한다 (작업 끝)

5. Resource Server가 scope에 해당하는 권한들을 Client에게 부여할 것인지 확인하는 메시지를 전송한다.

   • 어떠한 정보들을 Client가 요청하고 있으며, 접근하도록 허용할 것인지를 묻는 창이 뜬다.

6. Resource Owner가 허용 시, Resource Server는

   • 어떤 Resource Owner(=User)가
   • 어떤 Client에게
   • 어떤 scope에 대한 작업을 허용했는지

   에 대한 정보를 가지게 된다.

5. Resource Server의 승인

Resource Server는 Client가 등록된 Client가 맞는지 확인하기 위해서 Resource Owner을 통해서 Client에게 Authorization code를 전달합니다. 이 값을 받은 Client는 이 값과 Client secret의 값을 Resource Server로 전송해서 Client의 신원을 Resource Owner에게 증명합니다. 여기서는 이 과정을 다룹니다.

Resource Owner가 승인했다고 해서 Resource Server가 바로 액세스 토큰을 발급해 주지는 않는다.

• Authorization Code를 발급하고
• Resource Owner에게 Authorization Code를 전송한다
  • HTTP header : Location : https://client/callback?code=3
  • 리다이렉션. 즉 Resource Server가 Client의 웹 브라우저에게 https://client/callback?code=3이라는 주소로 이동하도록 명령하는 것

이 과정에서 Client는 자기도 모르게 code=3이라는, Client의 Authorization Code값을 갖게 된다.

---

이제 Client는 Resource Owner를 통하지 않고, Resource Server로 직접 요청한다 - 아래와 같은 주소로

https://resource.server/token?grant_type_authorization_code&code=3&redirect_url=https://client/callback&client_id=1&client_secret=2

• grant_type_authorization_code : Authorization Code방식을 통해 접속하겠다.
  • 4가지 방식 중 하나의 방식이다.
• code : Authorization Code
• Redirect URL
• Client ID
• Client Secret

즉 Authorization Code와 Client Secret라는 두 가지 비밀 정보를 제출하며 접속하는 것

---

Resource Server는

• 요청한 정보가 Authorization Code에 해당하는 정보와 일치하는지 확인
  • Client ID, Client Secret, Redirect URL 이 모두 완전히 일치할 때만 그 다음 단계(액세스 토큰 발급)로 진행한다.

6. Access Token

OAuth의 핵심인 access token의 값을 발급 받는 과정을 다룹니다.

5.에서 Client에 대한 모든 확인이 끝나면 드디어 Access Token을 발급해 준다. (=OAuth의 목적)

이는 Resource Server의 필요한 데이터에 대한 접근권한을 주는 것이다.

---

Client에 대한 모든 확인이 끝나면, Resource Server는 이제 Authorization Code값을 지운다. (같은 인증 작업을 또 하지 않도록)

그 다음 Access Token을 발급해 Client에게 응답해 준다.

Client는 Access Token 정보를 저장해 두고, 데이터를 요청할 때 사용한다.

Resource Server는 해당 Access Token을 보고

• 어떤 Resource Owner(User)에 대한
• 어떤 기능에 필요한 정보(scope)들을

주면 되는지 확인한 다음 해당 데이터를 보내 준다.

7. API 호출

API가 무엇인지, Access Token을 이용해서 API를 호출하는 방법이 무엇인지를 살펴봅니다.

이제 Client는 Access Token을 가지고 Resource Server의 데이터를 이용해야 한다.

어떻게? Resource Server가 Client에 대해 정해 준 방식대로 이용해야 한다.

이 방식을 API(Application Programming Interface)라고 한다.

API

API는 Client가 Resource Server를 호출할 때, 접점에 있는 조작장치이다.

예를 들어 Google Calendar를 쓰고 싶다면 'Google Calendar API'라고 구글링 해 문서를 참고하며 따라한다.

제시된 API들 중 원하는 기능의 링크를 사용하면 된다. 하지만, 해당 API들을 사용하기 위해서는 Access Token이 필요하다.

각 언어/프레임워크마다 Access Token을 가져오는 방식이 다르니 찾아서 학습할 수 있다.

OAuth Access Token 값을 직접 URL에 넣어 요청할 수도 있지만, HTTP Header에 넣어 요청하는 방식이 더 권장되는 방식이다.

curl 이라는 프로그램을 이용하면 더 쉽게 이용할 수 있다.

8. refresh token

Access token은 수명이 있습니다. Access token의 수명이 다했을 때 새로운 access token을 발급 받는 방법이 refresh token입니다. 이것에 대해서 알아봅니다.

Access Token은 수명이 있다. 짧게는 1~2시간, 길게는 60일 등

Access Token의 수명이 끝나면 Access Token을 재발급받아야 하는데,

그 때마다 모든 인증 과정을 다시 거치면 힘든 일이다 (그래도 필수로 하게 하는 시스템도 있다)

더 쉽게 Access Token을 재발급받는 것이 refresh token이다.

검색키워드 : OAuth 2.0 RFC

(RFC : 인터넷 관련 기술들의 표준안)

보통은 6.에서 Access Token을 발급할 때, Refresh Token을 함께 발급해 준다.

우리가 가진 Access Token의 수명이 끝나면,

함께 발급받은 Refresh Token을 Authorization Server에 제출함으로써 Access Token을 재발급받는다.

(경우에 따라 Access Token과 Refresh Token을 둘 다 재발급해 주기도 한다)

9. 수업을 마치며

여기까지 오시느라 고생하셨습니다. 여기서는 앞으로 공부할만한 주제를 소개해드리겠습니다. 축하합니다!

인증체계

Federated Identity

: 다른 서비스와의 연합을 통해 사용자를 식별하는 인증체계

(Login with Google 과 같은 서비스들)

API 사용을 위한 지식들

API를 잘 다루는 데 중요한 배경지식들

• Restful API

• JSON

• XML