외부에서 개발된 소프트웨어를 이용하기 위해서는 연결을 해야 한다. 연결은 API(Application Programming Interface)를 통해서 이루어진다. API가 동작하기 위해서는 외부에서 접근한 서비스 요청을 승인하는 방식이 필요하다. OAuth 2.0은 로그인하지 않고도 제3자에게 서비스를 제공할 수 있도록 하는 표준 사용자 인증 프로토콜이다.
OAuth 2.0은 마이데이터 서비스의 핵심 기술이다. 마이데이터는 개인이 자신의 데이터를 확인하고, 통제하고, 사용할 수 있게 하는 제도이다. 개인이 자신의 데이터를 활용하기 위해서는 마이데이터 서비스를 제공하는 회사에게 자신의 데이터를 보낼 수 있어야 한다. OAuth 2.0이 기술 표준이 되어 있다.
본 글은 OAuth 2.0 Authorization Framework(이하 ‘OAuth2’)에 대한 소개와, 이 프레임워크가 마이데이터 생태계 관점에서 중요한 이유에 대해 설명하고자 한다.
1부에서는 용어를 설명하고, 등장 배경과 역할을 설명한다.
2부에서는 OAuth2의 핵심 구성 요소 및 절차적 흐름을 설명한다.
3부에서는 마이데이터 생태계 관점에서OAuth2의 의미에 대해 설명한다.
4부에서는 OAuth2의 국내외 현황과 마이데이터 제도 도입에 대해 설명한다.
용어에 대해서
[그림 1] 인증과 승인
출처: https://techdifferences.com/difference-between-authentication-and-authorization.html
1. 인증(Authentication) - 신원을 확인하는 것
인증은 자신이 A라고 하는 개인 또는 기관이 과연 정말로 A가 맞는건지 신원을 확인하는 행위를 의미한다. 인증이 됨으로써 어떠한 상태에 변화가 생기는 것은 아니다. 인증을 함으로써 A라는 사람의 신원이 확인되고 A가 소유한 특정 자원에 대한 주권을 행사할 수 있게 되지만, 이 주권은 원래부터 A가 가지고 있던 것이다. 다시 말해, A라는 사람을 인증함으로써 이전에 없던 주권이 새로 생기지는 않는다는 말이다.
인증은 주권을 행사할 자격에 대한 증명을 하는 절차다. 따라서 시스템 및 데이터 관리 체계의 보안성과 매우 높은 연관이 있고 빈틈없게 구현해야 하는 기능이다.
2. 승인 (Authorization) - 권한을 부여하는 것
네이버 국어 사전은 “승인”에 대해 5가지의 정의를 제공하는데, 이들 중 5번째 정의가 본문에서 일컫는 승인의 개념과 상통한다. 그 정의는 다음과 같다.
법률 공법(公法)에서, 국가나 지방 자치 단체의 기관이 다른 기관이나 개인의 특정한 행위에 대하여 행하는 승낙이나 동의. (출처: 네이버 국어사전)
OAuth2에서 말하는 승인(Authorization)은 위의 정의에 비추어 생각하면 이해하기 쉽다. 위의 정의에서 “국가나 지방 자치 단체의 기관”을 “통제된 자원의 주인”으로, “다른 기관이나 개인”을 “클라이언트”로, 그리고 “특정한 행위”를 “통제된 자원에 접근하는 행위”로 바꾸면 OAuth2의 승인을 설명하게 된다.
정확히 말하자면 OAuth2의 승인은 다음과 같이 정의할 수 있다.
인증이 되기 전과 후, 인증을 수행한 측이나 인증 대상의 상태에는 아무런 변화가 없다. 인증 전에 없던 자격이 인증 후에 생기지 않는다는 말이다. 반면에 승인은 이전 상태와 다른 새로운 상태가 된다. 승인 받은 대상은 새로운 자격이 생기게 되기 때문이다.
OAuth2의 등장 배경
권한이 부여되는 경우라면 반드시 권한 소유자에 대한 인증 절차를 거친다. 웹 상에서 소유자를 인증하는 가장 대표적인 방식은 ID와 비밀번호로 로그인하는 방식이다.
로그인 방식의 인증은 인터넷 초창기부터 많이 사용되고 있다. 일반적으로 로그인 방식의 인증은 HTML기반으로 브라우저에 사용자가 입력한 로그인 정보를 서버로 전송하는 경우가 많았다. 서버는 수신한 로그인 정보로 사용자 인증이 성공할 경우 쿠키에 세션 값을 저장함으로써 권한이 부여됐었다. 이 경우 한번의 인증으로 세션이 비활성화될 때까지 사용자는 통제된 기능 및 자원의 접근이 가능했다. 매우 간편하고 효율적인 인증 방식으로서 지금까지도 많은 웹서버들이 사용하고 있다.
하지만 이러한 쿠키 기반 권한 부여는 몇가지 단점 및 취약점을 내재하고 있다.
- 쿠키 기반 권한은 일반적으로 Stateful하다. 서버에 요청이 접수될 때마다 데이터 베이스를 통해 현재 상태에 대한 확인을 해야만 하는 것이다. 이에 따라 서버 측에서는 권한의 유효성을 반복적으로 확인하는 비용이 발생하게 된다. 아울러 권한 부여 프로세스를 앱서버로부터 분리시키기(decoupling)가 어렵다는 단점이 있다.
- 쿠키는 보통 도메인에 속한 경우가 많다. 여러 도메인과 상호작용하는 앱일 경우, 추가적으로 설정해야 할 사항들이 생길 수 있다.
- 쿠키 기반 승인은 모바일 앱에 적합하지 않다.
- 쿠키 기반 승인은 사용자가 서로 다른 서비스 간에 자신의 데이터를 공유하기 어렵다.
위와 같은 단점들 등을 해결하기 위해 IETF(Internet Engineering Task Force)가 만들어낸 프레임워크가 OAuth2이다. IETF가 작성한 RFC 6749에는 OAuth2에 대한 모든 것이 설명되어 있다. RFC 6749는 공개적으로 검토(public review)과정을 통과했고 최종적으로 IESG(Internet Engineering Steering Group)가 승인하여 발표된 인터넷 표준 트랙 문서(Internet Standards Track document)이다. OAuth2는 기존의 OAuth 1.0(RFC 5849)을 대체한 프레임워크이기도 하다.
OAuth2 의 네 가지 역할
[그림 2] OAuth2의 역할 / 출처: http://tutorials.jenkov.com/oauth2/roles.html
본문에서는 역할을 명확하게 하기 OAuth2에서 정의된 역할들을 한글로 앱(Client), 데이터 제공기관(Resource Server), 권한 제공기관(Authorization Server), 그리고 사용자(Resource Owner)라고 명칭한다.
1. 앱(Client)
앱은 사용자 데이터를 활용하여 서비스를 제공하려는 응용프로그램이다. 앱이 사용자 데이터에 접근할 권한을 요청하면서OAuth2의 절차적 흐름이 시작되고, 앱이 사용자 데이터를 받게 되면 끝난다.
2. 데이터 제공기관(Resource Server)
데이터 제공기관은 사용자의 데이터를 보유하고 유효한 접근 권한을 부여 받은 앱이 요청하면 사용자 데이터를 제공하기도 하는 서버를 의미한다. 경우에 따라 데이터 보유기관이라고 일컬어지는 경우도 있다. 그러나, 필자는 OAuth2에서 데이터를 보유하고 있는 역할보다는 접근 요청의 유효성을 분별하여 사용자가 동의한 앱에게만 데이터를 제공하는 역할이 의미가 있다고 생각한다. 따라서 본문에서는 데이터 제공기관으로 명칭하기로 한다. 데이터 제공기관은 앱이 접근 토큰을 사용자 데이터와 교환할 수 있는 API를 제공하는 기관이기도 하다.
3. 권한 제공기관(Authorization Server)
권한 제공기관은 사용자 데이터에 접근한 권한을 제공하는 서버이다. 앱의 접근 요청에 따라 사용자에게 앱에 대해 등록된 정보 및 앱이 요청한 데이터 항목, 활용하려는 목적 및 기간 등에 대한 정보를 제시하고 사용자의 동의 여부를 문의하는 역할을 한다.
소규모 시스템의 경우 하나의 개체가 권한 제공기관과 데이터 제공기관의 2가지 역할을 수행하는 경우도 있으나, 규모가 클수록 권한 제공기관과 데이터 제공기관을 분리해서 구현하는 경우가 많다.
4. 사용자(Resource Owner)
사용자는 OAuth2의 최고 권력자이다. 데이터 제공기관 입장에서는 데이터 보호를 부탁한 고객이고, 앱의 입장에서는 가치를 창출하기 위해 필요한 데이터의 주인이다. 사용자는 임의로 자신의 데이터에 대한 접근 권한을 부여, 거부 또는 철회를 할 수 있는 데이터 주체이다. 아울러, 사용자는 제공할 데이터의 범위 및 기간 등에 대한 결정도 내릴 수 있다.
OAuth2 에 사용되는 데이터
1. 앱의 등록정보
OAuth2가 작동하기 위해서 앱은 사전에 권한 제공기관에 등록해야 한다. 새로운 앱이 등록할 때 일반적으로 앱이 제공할 서비스의 명칭, 웹사이트, 로고 등의 기본정보를 제출한다. 아울러, 웹서버 앱, 브라우저 기반 앱 또는 모바일 앱의 경우에는 반드시Redirect URI에 대한 정보를 추가적으로 등록해야 한다.
2. Redirect URI
권한 제공기관은 사용자가 앱에게 권한 부여하는 것에 사용자가 동의하면 사용자를 앱의 등록된 Redirect URI로 이동(redirection)시킨다. 만일 등록되지 않은 Redirect URI를 담은 요청을 받게 되면 그 요청은 무효 처리된다. 기존에 등록된 Redirect URI의 범위에 한해서 사용자를 연결시킴으로써 방지할 수 있는 공격들이 있기 때문이다. 또한, 모든 HTTP 기반 Redirect URI는 반드시TLS 로 보안이 되어있어야 하므로 “https”로 시작하는 URI만 등록이 가능하다. 이 제약조건이 존재하는 이유는 승인 과정에서 토큰 노출에 대한 방어를 하기 위해서이다.
3. Client ID와 Client Secret
새로 등록하는 앱은 권한 제공기관으로부터Client ID와 Client Secret을 발급받는다. Client ID는 공개하는 정보로서 로그인 웹 페이지 또는 JavaScript에 포함될 수 있는 정보이다. 반면에 Client Secret은 노출되면 안되는 정보이다. Client Secret의 노출을 방지할 수 없는 Single-Page JavaScript 앱 또는 Native 앱의 경우 Client Secret을 사용하지 않는다. 이럴 경우 애초부터 Client Secret을 발급하지 않는게 바람직하다.
- 본 칼럼은 'OAuth 2.0 소개 [2부] : OAuth 2.0의 작동 메커니즘'으로 이어집니다
[관련글]
OAuth 2.0 소개 [2부] : OAuth 2.0의 작동 메커니즘
OAuth 2.0 소개 [3부] : 마이데이터 적용을 위한 세가지 기술
[참고자료]
▶금융결제원Testbed Developers의 OAuth2:
▶금융보안원, “전자금융과 금융보안”, 제3호, 2016-01:
▶한국정보통신기술협회/정보통신산업진흥원, ‘클라우드 상호운용성 확보 가이드라인’
▶네이버 API 공통 가이드의 내이버 아이디로 로그인:
