OAuth와 OAuth 2.0
위키백과에 따르면 'OAuth(Open Authorization)'는 인터넷 사용자들이 비밀번호를 제공하지 않고, 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 위임을 위한 개방형 표준이다.
구글 로그인 기능을 떠올리면 편한데, 사용자가 웹 서버에 직접 ID와 PW를 건네주지 않고도 구글 계정의 일부 접근 권한을 부여할 수 있다.
OAuth 2.0은 다양한 클라이언트 환경에 적합한 인증(Authentication) 및 인가(Authorization)의 부여(위임) 방법(Grant Type)을 제공하고, 그 결과로 클라이언트에 접근 토큰(Access Token)을 발급하는 것에 대한 구조(framework)로 볼 수 있다.
구글 로그인 과정을 예시로 들자면, 웹 서버가 특정 사용자에 대한 Access Token을 구글에 넘겨주고, 구글이 그 토큰에 맞는(권한에 맞는) 정보만을 리턴해준다.
OAuth 2.0의 구성요소
client
클라이언트는 특정한 개인 또는 회사가 만든 서비스를 의미한다. 일반적인 웹/앱 서비스를 의미하지만 client라고 불린다. 그 이유는 Resource Server(구글, 카카오, 네이버 등)의 입장에서는 이 웹 서비스가 클라이언트이기 때문이다.
Resource Owner
특정 서비스를 사용하려는 사용자다. 대부분 개인정보(Resource)의 소유자를 의미한다.
Resource Server
사용자의 개인정보를 가지고 있는 서버를 의미한다. ex)구글, 카카오, 네이버 등
client는 Access Token을 Resource Server로 보내 사용자의 정보를 얻는다.
Authorization Server
실질적으로 권한 부여 기능을 담당하는 서버다.
사용자(실제 유저)는 자신의 계정 정보를 웹 서비스에 넘겨 Authorization code를 받는다. client(웹 서비스)는 사용자로부터 받은 Authorization code를 넘겨 Access Token을 받는다.
OAuth 2.0의 동작 예시 (개발자=client 입장)
-
실제 사용자가 SNS 로그인 기능을 호출하면 서비스는 Client ID와 Redirect URI를 보내준다. 이때 실제 사용자는 해당 정보들을 이용해서 실질적은 SNS 로그인을 진행하게 된다.
- 이때 개발자에겐 ID와 PW에 대한 정보가 포함되어 있지 않기 때문에 상대적으로 안전하다.
-
이후 SNS 로그인 페이지를 실제 사용자에게 제공하고 실제 사용자는 개발자에게 ID와 PW를 노출하지 않고 로그인을 수행할 수 있다.
-
Authorization Server는 Authorization code를 실제 사용자에게 전달하고 이제 Authorization code를 Redirect URI로 전달하면 개발자는 Authorization code를 받아서
Authorization Server의 API를 통해 보내준다. -
Authorization Server는 Access Token을 client(개발자)에게 보내준다.
-
개발자는 그 토큰을 통해 API를 호출하여 요청된 자원을 전달받아 그것을 이용하여 실제로 회원가입, 로그인 등의 기능을 수행하여 실질적인 서비스를 제공한다.
Access Token을 획득하는 과정에서 Authorization Code 발급 과정이 들어간 이유?
Redirect URI를 통해 Authorization Code를 발급하는 과정이 생략된다면, Authorization Server가 Access Token을 Client에 전달하기 위해 Redirect URI를 통해야 한다. 이때, Redirect URI를 통해 데이터를 전달할 방법은 URL 자체에 데이터를 실어 전달하는 방법밖에 존재하지 않는다. 브라우저를 통해 데이터가 곧바로 노출된다.
Access Token은 민감한 데이터이다. 이렇게 쉽게 노출되어서는 안된다. 이런 보안 사고를 방지 Authorization Code를 사용하는 것이다.
Redirect URI를 프론트엔드 주소로 설정하여, Authorization Code를 프론트엔드로 전달한다. 그리고 이 Authorization Code는 프론트엔드에서 백엔드로 전달된다. 코드를 전달받은 백엔드는 비로소 Authorization Server의 token 엔드포인트로 요청하여 Access Token을 발급한다.
이런 과정을 거치면 Access Token이 항상 우리의 어플리케이션과 OAuth 서비스의 백채널을 통해서만 전송되기 때문에 공격자가 Access Token을 가로챌 수 없게된다.
