10월 22일 (금) OAuth 2.0

Southbig·2021년 11월 22일

소셜로그인

전통적으로 직접 작성한 서버에서 인증을 처리해주는 것과는 달리, OAuth는 인증을 중개해주는 메커니즘이다
보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜이다
즉, 이미 사용자 정보를 가지고 있는 웹 서비스(GitHub, google, facebook 등)에서 사용자의 인증을 대신해주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능해진다

OAuth가 모든 것을 해결해주는 솔루션은 아니다 여전히 사용자 정보가 내 서버에 저장되는 것은 변함이 없다
OAuth는 인증(Authentication)을 다른 서비스에 맡길 뿐, 접근 권한 관리(Authorization)는 순전히 내 서버의 몫이다 그러므로, OAuth의 작동 방식을 알기 위해서는 기존 인증 방식에 대한 이해가 필수다

OAuth 란?

OAuth2.0은 인증을 위한 표준 프로토콜의 한 종류
보안된 리소스에 액세스하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜 중 한 방법이다

OAuth 는 언제, 왜 쓸까?

유저 입장에서 생각해보자면, 우리는 웹상에서 굉장히 많은 서비스를 이용하고 있고 각각의 서비스들을 이용하기 위해서는 회원가입 절차가 필요한 경우가 대부분이다
그 서비스별로 ID와 Password를 다 기억하는 것은 매우 귀찮은 일이다,
OAuth 를 활용한다면 자주 사용하고 중요한 서비스들(예를 들어 google, github, facebook) 의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 할 수 있다

뿐만 아니라 OAuth는 보안상의 이점도 있다
검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 하기 때문에 더 안전하게 사용할 수 있다

OAuth에서 꼭 알아야 할 용어

Resource Owner : 액세스 중인 리소스의 유저다
User가 구글 계정을 이용하여 App에 로그인할 경우, 이때 Resource owner은 User가 된다
Client : Resource owner를 대신하여 보호된 리소스에 액세스하는 응용프로그램이다
클라이언트는 서버, 데스크탑, 모바일 또는 기타 장치에서 호스팅할 수 있다 (APP)
Resource server : User의 리소스들을 가지고 있는 서버, client의 요청을 수락하고 응답할 수 있는 서버, 리소스서버는 Authorization server를 통해 엑세스 토큰을 발급 받는다
Authorization server : Resource server가 액세스 토큰을 발급받는 서버, 즉 클라이언트 및 리소스 소유자를 성공적으로 인증한 후 액세스 토큰을 발급하는 서버를 말한다
Authorization grant : 클라이언트가 액세스 토큰을 얻을 때 사용하는 자격 증명의 유형
(grant type은 클라이언트 어플리케이션이 엑세스 토큰을 얻는 방법, 그 중 대표적인 방법이 Authorization grant다)
Authorization code : access token을 발급받기 전에 필요한 code
(엑세스 토큰을 발급받기 위해선 client ID와 client secret이 필요한데, 이 두가지가 포함된 일종의 허가증을 Authorization code라고 한다)
client ID로 이 code를 받아온 후, client secret과 code를 이용해 Access token 을 받아온다
Access token : 보호된 리소스에 액세스하는 데 사용되는 credentials이다
(위의 과정으로 발급받은 토큰을 엑세스 토큰이라고한다, 클라이언트에 발급된 권한을 나타내는 문자열 타입으로 되어있다)
Authorization code와 client secret을 이용해 받아온 이 Access token으로 이제 resource server에 접근을 할 수 있다
Scope : scope는 토큰의 권한을 정의한다
주어진 액세스 토큰을 사용하여 액세스할 수 있는 리소스의 범위

Resource Owner : User
Client : APP
Resource server : 이미 사용자 정보를 가지고 있는 웹 서비스
Authorization server : 이미 사용자 정보를 가지고 있는 웹 서비스
Scope : 이미 사용자 정보를 가지고 있는 웹 서비스의 엑세스할 수 있는 리소스의 범위

소셜 로그인 로직 플로우

Grant Type 종류

Grant Type 이란 ?
Client가 엑세스 토큰을 얻는 방법

각 grant type들은 웹앱, 네이티브앱, 웹브라우저를 출시할 능력이 없는 장치, 서버대 서버 애플리케이션이든 특정 용도에 최적화 된다

Authorization code Grant Type
Implicit Grant Type
client Credentials Grant Type
Resource Ouner Credentials Grant Type
Refresh Token Grant Type

Authorization code Grant Type

엑세스 토큰을 받아오기 위해서 먼저 Authorication code를 받아 엑세스 토큰과 교환하는 방법

유저가 승인을 한 후에 인증서버에서 엑세스 토큰을 얻기 위해서 Authorization code응 받고,
엑세스 토큰과 교환을 한다

Authorization code 절차를 거치는 이유는 보안성 강화에 목적이 있다
Client에서 client-secret을 공유하고 엑세스 토큰을 가지고 오는 것은 탈취될 위험이 있기 때문에,
Client에서는 (Client Id만 이용해서) authorization code 만 받아 오고,
Server에서 (Client secret까지 포함해서) Access token 요청을 진행한다