OAuth2.0로 사회적인 어플리케이션 만들기 👯

1. OAuth2.0이란?
2. OAuth2.0에서의 주요 주체
3. OAuth2.0 동작 방식

1. OAuth2.0이란?

요즘은 대부분의 어플리케이션에서 소셜로그인 기능을 제공합니다. 또한 어플리케이션끼리 상호작용하는 기능도 요즘에는 대부분 가지고 있습니다. 인스타그램에 피드를 남기면 페이스북에도 똑같은 피드를 올려준다던지, Slack에서 Google drive를 사용한다던지. 이런 사회적인(?) 어플리케이션을 만들 수 있도록 해주는 기술이 바로 OAuth2.0입니다. OAuth2.0은 구글, 애플과 같은 플랫폼에서 특정한 사용자 데이터에 접근하거나 데이터를 추가/수정하기 위해 제3자 클라이언트가 사용자의 접근 권한을 위임(Delegated authorization) 받을 수 있는 표준 프로토콜입니다.

예를 들어 Notion calendar에서 사용자의 구글 캘린더에 있는 일정들도 함께 표시하고 싶다고 해봅시다.

만약 OAuth없이 구현한다고 하면 사용자가 노션 캘린더에 구글 아이디와 비밀번호를 주고, 노션 캘린더는 사용자의 아이디와 비밀번호로 직접 구글캘린더에 로그인하여 사용자의 일정 데이터에 접근할 것입니다.

이렇게 구현되면 사용자 입장에서는 노션캘린더에 자신의 구글 아이디와 비밀번호를 알려주는 것이 부담스럽고 노션 캘린더도 사용자의 구글 아이디와 비밀번호를 가지고 있는 것이 보안적으로 부담스러울 것입니다. 구글 캘린더도 제3자 어플리케이션(노션 캘린더)이 자신의 사용자 정보를 가지고 있는 것이 위험하다고 생각할 것입니다. 이런 상황을 해결해줄 수 있는 기술이 OAuth2.0입니다. 위 상황을 OAuth2.0 기술을 사용하여 구현하였을 때는 어떻게 바뀌는지 보겠습니다.

OAuth를 적용하게 되면 사용자가 로그인을 직접합니다. 그리고 사용자의 구글 캘린더 데이터 접근 권한을 구글 캘린더가 노션 캘린더에게 직접 부여합니다. 즉, 인증은 사용자가 직접하고 권한은 서비스가 직접 받습니다. OAuth는 인가를 위한 프로토콜입니다. 어플리케이션 입장에서는 권한만 얻으면되는데, 이를 위해서는 인증이 필요하니 인증과 인가의 주체를 분리하자는 것입니다. 우선 OAuth가 왜 필요한지, 어떤 기술인지는 여기까지 간단하게만 보고 동작방식은 아래에서 자세하게 살표보도록 하겠습니다.

2. OAuth2.0에서의 주요 주체

Resource Owner	인증을 수행하는 주체. 즉, 사용자
Client (3rd-parth application)	권한을 위임받는 주체
Authorization Server	인증을 검증하고 원한을 부여하는 주체(인증을 처리하는 서버)
Resource Server	인가를 수행하고 리소스를 제공하는 주체(데이터를 가지고 있는 서버)

3. OAuth2.0 동작 방식

https://datatracker.ietf.org/doc/html/rfc6749#section-1.2

공식 문서에서 설명하고 있는 프로토콜 흐름 도식 입니다.

(A) 클라이언트는 사용자에게 인증을 요청합니다.

(B) 사용자는 인증(로그인)을 하면 클라이언트는 resource owner의 인증인 credential을 받습니다.

(D) 인증 서버 요청한 클라이언트와 credential이 유효하면 access token을 발급해줍니다.

(E) access token을 발급받은 클라이언트는 사용자 데이터를 access token과 함께 요청합니다.

(F) 리소스 서버는 access token이 유효하면 사용자 데이터를 클라이언트에게 제공합니다.

간단한 동작 방식은 위와 같습니다. 아래에서 단계별로 어떤 데이터를 주고받아 인증과 인가를 처리하는지 차례대로 짚어보겠습니다.

1) OAuth 등록

우선, Authorization Server에 클라이언트를 등록해야합니다. 사용하고자하는 인증 플랫폼이 여러개라면 각각 등록을 해주어야 합니다. 여기서는 구글에서 등록을 해보겠습니다. GCP(Google Cloud Platform)에서 프로젝트 생성 후, API 및 서비스 탭의 사용자 인증 정보 만들기 + OAuth 클라이언트 ID를 클릭합니다.

클라이언트 이름은 클라이언트를 식별하는 용도로 사용되는 이름이므로 어플리케이션 이름을 입력하겠습니다. 리디렉션 URI는 사용자가 인증을 완료했을 때 인증 서버가 클라이언트 어플리케이션으로 다시 리다이렉션할 URL입니다. 리디렉션 URI까지 입력 후, 만들기를 클릭하면 아래와 같이 클라이언트 id와 클라이언트 보안 비밀번호(client secret)를 받을 수 있습니다. 클라이언트 id와 클라이언트 secret은 나중에 인증 서버가 이 클라이언트가 유효한 클라이언트인지 확인하기 위한 비밀번호이므로 안전하게 보관해야합니다.

이렇게 등록을 하면 현재 클라이언트와 인증 서버가 client id, client secret, redirect URL 정보를 가지고 있습니다.

2) Resouce Owner의 승인

이제 사용자, 즉 Resource owner의 승인을 받는 과정을 알아보겠습니다. 소셜 로그인을 예시로 보겠습니다. 사용자가 아래에 Sign in with Google 버튼을 클릭하면 아래와 같은 주소로 이동하게 됩니다.

구글의 OAuth2.0 endpoint는 https://accounts.google.com/o/oauth2/v2/auth 이고 client_id, redirect_uri, response_type, scope을 각각 쿼리 파라미터로 합니다.

+) 구글의 인증 API 공식 문서는 아래 페이지에서 보실 수 있습니다.

웹 서버 애플리케이션용 OAuth 2.0 사용 | Authorization | Google for Developers

이 페이지는 Cloud Translation API를 통해 번역되었습니다. 의견 보내기 웹 서버 애플리케이션용 OAuth 2.0 사용 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요. 이

developers.google.com

사용자가 버튼을 클릭하여 URL로 접속하면 로그인 페이지가 열립니다. 그러면 사용자는 로그인을 하고 로그인이 성공하면 사용자가 요청한 client id와 redirect url이 인증서버가 가지고 있는 client id와 redirect과 같은지 검증합니다. 값이 같다면 인증 서버는 사용자 id와 사용자가 클라이언트의 접근에 동의한 범위(scope)을 저장해둡니다.

3) Authorization Server의 승인

이제 사용자의 인증 과정을 완료했으니 Authorization Server가 클라이언트에게 권한을 부여하는 과정을 보겠습니다.

사용자가 인증을 완료하고 클라이언트에게 자신의 데이터에 접근하는 것에 동의를 했다면 서버는 사용자에게 authorization code를 보냅니다. 전송 방식은 http 응답 헤더를 Location 헤더로 하여 redirection되도록 합니다. URL은 앞서 등록한 리디렉션 URI에 쿼리 파라미터에 code를 붙여서 전송합니다.

사용자는 해당 응답을 받으면 바로 리디렉션 URI로 리다이렉트하게되고 따라서 클라이언트는 URL에 붙어있는 쿼리 파라미터를 통해 Authorization code를 획득하게 됩니다. 이로써 인증서버와 Client 모두 사용자의 인증이 완료되었다는 credential인 Authorization code를 가지게 됩니다.

4) Access Token 발급

이제 클라이언트는 실제로 리소스 서버에 데이터를 요청할 때 제시할 access token을 발급받을 차례입니다. 아래와 같이 authorization code와 client id, client secret, redirect uri를 포함하여 POST 요청을 보냅니다. 인증 서버는 자신이 가지고 있는 정보과 받은 요청의 정보가 일치하는지를 검증한 후, 일치한다면 클라이언트에게 Access token을 발급해줍니다. 이제 클라이언트는 이 토큰으로 사용자의 정보에 접근할 수 있게됩니다!