OAuth 2

OAuth 2은 별도의 회원가입과정없이 로그인을 제공하는 플랫폼의 아이디만 있으면 서비스를 이용가능하도록 만들어준다. 외부 서비스에서도 인증을 가능하게 하고 그 서비스의 API를 이용하게도 해준다. 예를들면 쇼핑몰에서 네이버아이디나 구글계정만 있으면 쇼핑몰에 회원가입을 하지 않고도 물건 구매할 수 있는 서비스가 들 수 있다.

정리하면 OAuth 2은 다양한 플랫폼 환경에서 권환 부여를 위한 산업 표준 프로토콜이다. 간단하게 인증과 권한을 획득하는 것으로 볼 수 있다.

OAuth 2 구성

1) Resource Owner(사용자)

2) Authorization Server(인증 서버)

3) Resource Server(REST API)

4) Client

이용하려는 서비스이다. 예를들면 쇼핑몰같은 웹페이지를 들 수 있다.

OAuth 2의 토큰

1) 접근 토큰(Access Token)

접근토큰은 사용자의 데이터에 접근하기 위해 필요한 자격증명으로서 사용자가 특정 앱에게 부여한 권환에 대한 정보가 담긴 문자열이다. 접근 토큰에는 접근할 수 있는 특정 scope들과 접근가능한 기간 등 사용자가 동의한 사항들에 대한 정보가 담겨 있다. 이 정보에 기반하여 권한 제공기관 및 데이터 제공기관은 앱의 요청에 응하게 된다.

2) 재생 토큰(Refresh Token)

누구든지 유효한 접근 토큰을 보유하면 통제된 데이터에 접근할 수 있게 된다. 따라서 접근 토큰이 노출될 리스크를 감안해서 피해를 최소화하기 위해 일반적으로 접근토큰의 유효기간을 짧게 설정한다. 접근 토큰의 유효기간이 만효되었을 경우를 대비하여 앱 개발자는 재생토큰을 사용해 인증을 반복하게 하지 않고 새로 접근토큰을 발급 받을 수 있게 한다.

OAuth 2 인증종류

Authorization Code Grant

• 서버사이드 코드로 인증하는 방식

• 권한서버가 클라이언트와 리소스서버간의 중재역할

• Access Token을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지

• 로그인시에 페이지 URL에 response_type=code 라고 넘긴다

Implicit Grant

• token과 scope에 대한 스펙 등은 다르지만 OAuth 1.0a과 가장 비슷한 인증방식

• Public Client인 브라우저 기반의 어플리케이션(Javascript application)이나 모바일 어플리케이션에서 이 방식을 사용

• OAuth 2.0에서 가장 많이 사용되는 방식

• 권한코드 없이 바로 발급되서 보안에 취약

• 주로 Read only인 서비스에 사용

• 로그인시에 페이지 URL에 response_type=token 라고 넘긴다

Password Credentials Grant

• Client에 아이디/패스워드를 저장해 놓고 아이디/패스워드로 직접 access token을 받아오는 방식

• Client 를 믿을 수 없을 때에는 사용하기에 위험하기 때문에 API 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서만 사용하는 것을 추천한다

• 로그인시에 API에 POST로 grant_type=password 라고 넘긴다

Client Credentials Grant

• 어플리케이션이 Confidential Client일 때 id와 secret을 가지고 인증하는 방식이다

• 로그인시에 API에 POST로 grant_type=client_credentials 라고 넘긴다

OAuth 2의 흐름

• (A) (앱→사용자) 사용자 데이터에 접근하기 위한 권한을 요청한다. 개념상 앱이 사용자에게 요청하지만, 실제 구현은 앱과 사용자 사이에 권한 제공기관이 중개 역할을 하는 경우가 일반적이다.

• (B) (사용자→앱) 접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급한다. RFC 6749에서는 4가지 유형의 권한 부여 동의서를 정의하고 있다. 앱의 유형 및 권한 제공기관의 지원 여부에 따라 사용할 권한 부여 동의서의 유형이 결정된다.

• (C) (앱→권한 제공기관) 권한 부여 동의서를 제출하여 접근 토큰을 요청한다. 접근 토큰은 사용자 데이터를 잠근 자물쇠를 여는 열쇠이다.

• (D) (권한 제공기관→앱) 권한 부여 동의서를 확인하여 사용자가 동의한 데이터 항목, 범위 및 기간 등에 대한 정보가 담긴 접근 토큰을 제공한다. 즉, 사용자 데이터에 접근할 때 사용할 열쇠를 제공하는 셈이다.

• (E) (앱→데이터 제공기관) 접근 토큰을 제출하여 사용자 데이터를 요청한다.

• (F) (데이터 제공기관→앱) 사용자 데이터를 제공한다. 이때 앱이 제출한 접근 토큰이 유효함을 확인하고, 접근 토큰의 정보를 확인하여 제공할 데이터 항목, 범위 및 유효기간이 정해진다.

참고

OAuth 2.0 소개http://www.2e.co.kr/news/articleView.html?idxno=208594

OAuth 란 무엇일까https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C