OAuth2의 토큰(Token)
OAuth2가 지원하는 여러가지 권한 부여 방식들의 공통점은 토큰을 사용한다는 점이다. 토큰의 종류로 접근 토큰(Access Token)과 재생 토큰(Refresh Token)이 있다. 하지만 OAuth2에서는 접근 토큰 및 재생 토큰이 가져야 할 특정한 형식을 지정하고 있지 않다. 다시 말해, 개발자가 임의로 토큰을 구현할 수 있도록 설계된 것이다. 실제로 현실에서는 대부분의 경우 토큰을 JWT 형식으로 구현하고 있다.
1. 접근 토큰(Access Token)
접근 토큰은 사용자의 데이터에 접근하기 위해 필요한 자격증명으로서 사용자가 특정 앱에게 부여한 권한에 대한 정보가 담긴 문자열이다. 접근 토큰에는 접근할 수 있는 특정 scope들과 접근 가능한 기간 등 사용자가 동의한 사항들에 대한 정보가 담겨 있다. 이 정보에 기반하여 권한 제공기관 및 데이터 제공기관은 앱의 요청에 응하게 된다.
2. 재생 토큰(Refresh Token)
누구든지 유효한 접근 토큰을 보유하면 통제된 데이터에 접근할 수 있게 된다. 따라서 접근 토큰이 노출될 리스크를 감안해서 피해를 최소화하기 위해 일반적으로 접근 토큰의 유효기간을 짧게 설정한다. 접근 토큰의 유효기간이 만료되었을 경우를 대비하여 앱 개발자는 재생 토큰을 사용할 수 있다. 재생 토큰을 활용하면 사용자에게 인증을 반복하게 하지 않고도 접근 토큰을 새로 발급 받을 수 있게 된다.
OAuth2의 프로토콜 흐름(Protocol Flow)
[그림1] OAuth 2.0을 구현한 프로토콜의 절차적 흐름의 개념도
본 개념도는 앞서 설명한 4가지 역할 사이의 상호작용을 나타내고 있으며 단계별로 다음과 같다.
(A) (앱→사용자) 사용자 데이터에 접근하기 위한 권한을 요청한다. 개념상 앱이 사용자에게 요청하지만, 실제 구현은 앱과 사용자 사이에 권한 제공기관이 중개 역할을 하는 경우가 일반적이다.
(B) (사용자→앱) 접근에 동의함을 증명하는 권한 부여 동의서(Authorization Grant)를 발급한다. RFC 6749에서는 4가지 유형의 권한 부여 동의서를 정의하고 있다. 앱의 유형 및 권한 제공기관의 지원 여부에 따라 사용할 권한 부여 동의서의 유형이 결정된다.
(C) (앱→권한 제공기관) 권한 부여 동의서를 제출하여 접근 토큰을 요청한다. 접근 토큰은 사용자 데이터를 잠근 자물쇠를 여는 열쇠이다.
(D) (권한 제공기관→앱) 권한 부여 동의서를 확인하여 사용자가 동의한 데이터 항목, 범위 및 기간 등에 대한 정보가 담긴 접근 토큰을 제공한다. 즉, 사용자 데이터에 접근할 때 사용할 열쇠를 제공하는 셈이다.
(E) (앱→데이터 제공기관) 접근 토큰을 제출하여 사용자 데이터를 요청한다.
(F) (데이터 제공기관→앱) 사용자 데이터를 제공한다. 이때 앱이 제출한 접근 토큰이 유효함을 확인하고, 접근 토큰의 정보를 확인하여 제공할 데이터 항목, 범위 및 유효기간이 정해진다.
OAuth2의 권한 부여 동의서(Authorization Grant)
접근 토큰을 요청하기 전에 앱은 사용자로부터 권한 부여에 대한 동의를 받아야 한다. 사용자의 동의는 권한 부여 동의서(Authorization Grant)의 형태로 제공된다. 권한 부여 동의서는 사용자가 데이터 접근을 허가했음을 나타내는 증명서로서 사용자가 앱에게 발급한다. 권한 부여 동의서를 근거로 앱은 권한 제공기관에게 사용자 데이터에 접근할 권한을 요청할 수 있다.
OAuth2는 4가지 유형의 권한 부여 동의서를 정의하고 있다. 승인 코드, 암묵적 동의, 사용자 비밀번호 유형, 그리고 앱 인증 유형이 있다. 아울러, 새로운 유형을 추가할 수 있는 확장 메커니즘도 지원한다.
본문에서는 가장 안전하고 많이 활용되는 승인 코드 방식의 절차적 흐름을 상세히 설명하기로 하고 나머지 3개의 유형은 간략한 설명만 한다.
1. 승인 코드(Authorization Code) 유형
사용자가 권한 제공기관에 연결하여 인증받고 권한 부여에 동의하면 승인 코드를 발급하는 유형이다.
승인 코드 유형은 신뢰성 높은 앱이 사용하기에 최적화 되어 있다. 승인 코드를 사용할 경우 접근 토큰 뿐만아니라 재생 토큰도 요청할 수 있다. 승인 코드는 리디렉션 기반 절차를 활용하기 때문에 앱은 사용자의 에이전트(user-agent)를 통해 사용자와 상호작용할 수 있어야 하며, 또한 권한 제공기관으로부터 Redirection URI에서 요청을 수신할 수 있어야 한다.
승인 코드 유형 권한 부여의 절차적 흐름은 다음과 같다.
[그림 2] 승인 코드 유형의 권한 부여 절차적 흐름
제3자 앱 및 서비스들에게 데이터를 자주 제공하는 플랫폼을 구축하고자 한다면 승인 코드를 활용하는 것이 가장 안전하다. 승인 코드를 활용한 권한 부여 방식의 절차적 흐름은 다음과 같다.
(A) 앱은user-agent 상으로 사용자를 권한 제공기관의 Authorization endpoint로 안내한다. 이때 앱은 앱의 식별자, 요청하는 scope, 로컬 상태 및 Redirection URI에 대한 정보도 함께 전송한다. 사용자가 접근 권한 부여에 동의하면 권한 제공기관은 사용자를 Redirection URI로 이동시키게 된다.
(B) 권한 제공기관은 사용자에 대한 인증을 수행하고 앱의 접근 요청에 대한 사용자의 동의 여부를 확인한다.
(C) 사용자가 앱의 접근에 동의하면 권한 제공기관은 승인 코드를 발급하고 앱이 요청한 Redirection URI로 user-agent를 안내한다. 이때 사용되는 Redirection URI에 승인 코드와 앱이 요청 시 제출한 로컬 상태에 대한 정보가 포함된다.
(D) 앱은 발급받은 승인 코드를 권한 제공기관의 Token endpoint에 제출하고 접근 토큰을 요청한다. 이 때 앱에 대한 인증 정보와 함께 앱이 승인 코드를 제공받은 Redirection URI를 제출함으로써 권한 제공기관은 앱의 요청이 유효함을 검증할 수 있도록 한다.
(E) 권한 제공기관은 앱을 인증하고 승인 코드가 유효함을 확인하며, 접근 토큰 요청에 제출된 Redirection URI가 승인 코드를 발급한 Redirection URI와 일치함을 확인한다. 모든 사항에 문제 없음이 확인되면, 권한 제공기관은 접근 토큰을 발급한다. 이때 요청되었을 경우 재생 토큰도 함께 제공한다.
2. 암묵적(Implicit) 유형
승인 코드 방식과 유사하나, 사용자가 권한 제공기관에 인증받은 후 승인 코드 대신에 접근 토큰을 바로 발급하는 유형이다.
암묵적 유형의 권한 부여 방식은 단일 페이지(Single Page) JavaScript 앱을 위해 만들어진 방식이다. 암묵적 유형의 권한 부여 방식의 절차적 흐름은 승인 코드 방식의 절차적 흐름과 매우 흡사하다. 차이점은 권한 제공기관로부터 승인 코드를 발급받지 않고 대신 바로 접근 토큰을 발급 받는다는 점이다. 보안을 유지하기 위해 Implicit 방식에서 재생 토큰은 금지되어 있다.
암묵적 유형 권한 부여의 절차적 흐름은 다음과 같다.
[그림 3] 암묵적 유형의 권한 부여 절차적 흐름
3. 사용자 비밀번호 인증(Resource Owner Password Credentials) 유형
사용자가 앱 상으로 ID/비밀번호로 로그인하여 인증하고 권한 부여에 동의하면 접근 토큰을 발급하는 유형이다.
사용자 비밀번호 인증 유형의 권한 부여 방식은 앱이 운영체제일 경우와 같이 사용자와 앱 사이에 높은 신뢰가 형성된 경우에 적합하다. 권한 제공기관은 다른 유형의 권한 부여 방식이 불가한 특수한 경우에만 사용자 비밀번호 인증 방식이 사용되도록 주의를 기울여야 한다.
사용자 비밀번호 인증 유형 권한 부여의 절차적 흐름은 다음과 같다.
[그림 4] 사용자 비밀번호 인증 유형의 권한 부여 절차적 흐름
4. 앱 인증(Client Credentials) 유형
권한 소유자가 앱인 경우 앱이 발급 받은 Client ID와 Client Secret을 확인하여 앱에 대한 인증을 수행하고 권한을 부여 받는 유형이다.
앱 인증 방식은 사용자가 앱인 경우에 활용된다. 앱 인증(Client Credentials) 유형을 사용하는 방법은 사용자 비밀번호 인증 유형을 사용하는 방법과 유사하다. 사용자 비밀번호 인증 방식에서 사용자 ID와 비밀번호가 사용되듯이 앱 인증 방식에서는 Client ID와 Client Secret을 통해 앱을 인증한다. 인증에 성공하면 권한 제공기관은 앱에게 접근 토큰을 발급하게 된다. 앱 인증 방식은 재생 토큰 사용을 금지한다.
앱 인증 유형 권한 부여의 절차적 흐름은 다음과 같다.
[그림 5] 앱 인증 유형의 권한 부여 절차적 흐름
- 본 칼럼은 'OAuth 2.0 소개 [3부] : 마이데이터 적용을 위한 세가지 기술'로 이어집니다
[관련글]
OAuth 2.0 소개 [1부] : API경제의 인증 기술, OAuth 2.0 소개
OAuth 2.0 소개 [3부] : 마이데이터 적용을 위한 세가지 기술
[참고자료]
▶ 금융결제원Testbed Developers의 OAuth2:
▶ 금융보안원, “전자금융과 금융보안”, 제3호, 2016-01:
▶ 한국정보통신기술협회/정보통신산업진흥원, ‘클라우드 상호운용성 확보 가이드라인’
▶ 네이버 API 공통 가이드의 네이버 아이디로 로그인:
