OAuth2.0
1. OAuth
정의
Open Authentication 의 약자로, 특정 웹사이트를 이용할 때 사용자들이 아이디와 비밀번호를 통해 새로 회원가입을 하는 것이 아니라 타 사이트에 이미 등록된 자신의 계정정보에 접근 권한을 부여/위임하는 과정에서 사용되는 개방형 표준 프로토콜이다.
배경
OAuth 프로토콜이 등장하기 전, 인증방식의 표준이 없었기 때문에 모든 서비스들은 사용자의 아이디와 비밀번호를 이용했는데, 때문에 보안상 취약할 수 밖에 없었다.
기본인증이 아닐 경우는 각 서비스제공자들이 개발한 방법대로 사용자를 확인해야했다.
Google(AuthSub), AOL(OpenAuth), Yahoo(BBAuth), Amazon(Web Service API) 등
이렇게 되면 이를 이용하는 어플리케이션은 모든 서비스의 방식대로 맞춰서 사용자의 인증을 구현해야한다.
OAuth는 이처럼 서비스제공자별로 각기 달랐던 인증방식을 표준화한 방식이다. 이 인증을 공유할 경우에는 어플리케이션끼리 별도의 인증이 필요하지 않다. 하나의 인증으로 여러 어플리케이션을 통합적으로 사용할 수 있게 된다.
2. OAuth 1.0(-> OAuth1.0a)
배경
트위터+다른 웹 개발자들이 인증과 권한부여를 동시에 제공할 수 있는 인증 프로토콜을 찾다가 없어서 하나 만들기로함. 그것이 OAuth1.0 임.
OAuth1.0은 2007년 10월에 확정되었으나 세션 고정 공격 보안 결함이 발견되어 2009년 6월에 이 문제가 개선된 OAuth1.0a 가 발표됨.
인증방식
고객(User) - 고객이 이용하려고 하는 어플리케이션(Consumer) - 고객의 정보를 가지고 있는 서비스 제공자(Service Provider) 등 3자가 상호작용하는 형태이다.
고객은 이용하고자 하는 어플리케이션에 접속하여 외부 서비스 제공자를 통해 로그인을 요청한다.
어플리케이션은 서비스 제공자에게 요청 토큰을 요청한다.
서비스 제공자는 요청 토큰을 발급한다.
어플리케이션은 고객을 서비스 제공자(트위터 등의 외부 서비스)로 이동시킨다. 이곳에서 사용자 인증이 수행된다.
서비스 제공자(트위터)는 고객을 다시 어플리케이션으로 이동시킨다.
어플리케이션이 접근 토큰을 요청한다.
서비스 제공자는 접근 토큰을 발행한다.
발급된 접근 토큰(Access Token)을 이용하여 어플리케이션이 사용자의 정보에 접근한다.
인증토큰의 장점
컨슈머가 아이디, 패스워드를 가지지 않고 API를 이용할 수 있다.
필요한 API에만 제한적으로 접근할 수 있도록 권한 제어가 가능하다.
사용자가 서비스 프로바이더의 관리페이지에서 권한 취소가 가능하다.
패스워드 변경시에도 인증토큰은 계속 유효하다.
장점
API를 인증함에 있어서 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증할 수 있다.
인증과 API 권한부여를 동시에 할 수 있다.
OAuth1.0이 만들어지기 전, 이미 Open ID 라고 서드파티 어플리케이션에 사용자 비밀번호를 노출하지 않는 방법이 개발되었으나, 해당 방법은 API의 권한부여기능을 가지고 있지 않았고, 인증 방법도 OAuth와는 달랐음.
기존 아이디, 비밀번호 입력 방식에 비해서는 보안이 향상되었다.
각 서비스 제공자별로 달랐던 인증방식을 하나로 통합하여 하나의 방식으로 여러 어플리케이션의 인증을 사용할 수 있게 되었다.
단점
구현이 복잡하다.
HMAC(Hash based Authentication Code)를 통해서 암호화를 해야하는 번거로움
인증토큰이 만료되지 않아서 토큰을 만료하려면 제공자의 어플리케이션의 비밀번호를 바꿔야 했다.
3. OAuth 2.0
등장배경
OAuth1.0a에서 불편하다고 느꼈던 모바일에서의 사용성 문제, Signature 생성과 같은 개발이 복잡하고 CPU를 많이 소비하는 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다.
OAuth1.0과 달라진 점
간단해졌다. 기능이 단순화 되었다.
이전에는 HTTPS 가 필수가 아니었기 때문에 Signature 를 생성하여 호출해야했다. 때문에 OAuth1.0a API를 테스트하기 위해서는 curl 을 사용하기도 힘들고 별도의 API콘솔을 사용해서 테스트를 해야했다. OAuth2.0의 Bearer 토큰 인증방식을 사용하면 더이상 Signature 가 필요없기 때문에 API 테스트나 예제를 만들 때, 간단하게 curl 등의 직관적인 방법을 사용해서 문서화하고 개발할 수 있게 되었다.
HTTPS를 통해서 암호화를 해서 과정의 단순화를 하였다.
다양한 인증방식이 제공된다.
OAuth1.0에서는 HMAC을 이용한 암호화라는 한가지의 인증방식만 제공되었다.
하지만 OAuth2.0에서는 시나리오별로 여러가지 인증방식을 제공하기 때문에 웹 브라우저, 모바일 등 다양한 시나리오에 대응할 수 있게 되었다.
API 서버에서 인증 서버와 리소스 서버가 분리되었다.
인증서버와 리소스 서버가 분리됨으로써 커다란 서비스로의 확장이 가능해졌다.
구성
Resource Owner : 사용자
Resource Server : API Server
Authorization Server : 인증서버 (API Server 와 같을수도 있음)
Client : 써드파티 어플리케이션
일반적인 인증방식
고객은 어플리케이션을 접근하고 외부 서비스(트위터 등)를 통한 로그인을 요청한다.
어플리케이션은 서비스 제공자에 로그인을 요청한다.
서비스 제공자는 로그인 페이지를 제공한다.
고객은 ID/PW 를 입력 후 로그인 요청한다.
서비스 제공자는 Authorization Code를 발급한 뒤, 어플리케이션으로 리다이렉트시킨다.
어플리케이션은 이제 Access Token 을 요청한다.
서비스 제공자는 Access Token 을 발급한다. 발급된 어플리케이션은 Access Token을 저장한다.
인증 완료가 되고 로그인에 성공하면 고객은 서비스를 요청한다.
이때 어플리케이션은 Access Token 으로 API를 호출한다.
서비스 제공자는 Access Token 을 검증한 뒤, 어플리케이션에 서비스를 제공한다.
응답을 받은 어플리케이션은 받은 응답으로 고객에게 서비스를 제공한다.
4가지의 인증방식
OAuth1.0이 HMAC 암호화 방식만 제공했던 것과 비교하여, OAuth2.0 의 경우, 인증방식이 다양하다. 하지만 1번과 2번을 제외하고는 3-legged OAuth가 아니기 때문에 Open API 에서는 많이 사용하지 않는다.
Client 의 두 종류
클라이언트에는 두 가지 종류가 있다. 하나는 Confidential Client 이고 다른 하나는 Public Client 이다.
Confidential Client
웹 서버가 API를 호출하는 경우 등과 같이 client 증명서(client_server)를 안전하게 보관할 수 있는 Client 를 의미한다.
Public Client
브라우저 기반 어플리케이션이나 모바일 어플리케이션과 같이 client 증명서를 안전하게 보관할 수 없는 client 를 의미한다. redirect_uri 를 통해서 client 를 인증한다.
Authorization Code Grant
Confidential Client 가 사용하는 방식
서버사이드 코드가 필요한 인증방식이며 인증과정에서 client_secret 이 필요하다.
로그인시에 페이지 URL에 response_type=code 라고 넘긴다.
Implicit Grant
Public Client 가 사용하는 방식
OAuth1.0a 와 가장 유사한 방식이다.
Client 증명서 필요 없음. 실제로 OAuth2.0에서 가장 많이 사용되는 방식
로그인시에 URL에 response_type=token 이라고 넘긴다.
Password Credentials Grant
2-legged 방식의 인증.
Client 에 아이디/비밀번호를 저장하고 이를 이용해 직접 access_token 을 받아오는 방식
Client를 신뢰할 수 없을 때는 매우 위험하기 때문에 믿을 수 있는 Client 에서만 사용할 것!
로그인시에 API 에 POST 로 grant_type=password 라고 넘긴다.
Client Credentials Grant
Confidential Client 일때 ID와 Secret 을 가지고 인증하는 방식
로그인 시에 API에 POST 로 grant_type=client_credentials 라고 넘긴다.
Access Token
정상적으로 사용자 인증을 마치면 Access Token을 발급받는다.
보호된 리소스에 접근할 때 권한 확인용으로 사용이 된다.
계정ID, PW 등 계정 인증에 필요한 형태를 Token 형태로 표현하기 때문에 리소스서버는 토큰 방식만 구현하여 대응할 수 있고, 사용자의 정보도 보안할 수 있어서 좋다.
Refresh Token
일반적으로 Access Token 을 발급받을 때, Refresh Token을 함께 발급한다.
Access Token 은 유효시간이 정해져있으므로 해당 시간이 지나게 되면 이후의 요청에 대해서는 오류를 응답한다.
이 경우, 미리 받아둔 Refresh Token 으로 다시 Access Token 발급을 요청하게 되면, Refresh Token 의 유효성을 검사한 뒤, 새롭게 Access Token 을 발급한다. Refresh Token 도 이때 새롭게 발급받게 된다.
4. 결론
OAuth2.0은 무엇인가
OAuth 는 Open Authentication의 약자로, 사용자가 어플리케이션을 이용할 때, 타 서비스에 이미 등록된 본인의 계정정보에 대한 접근권한을 부여하는 방식에서 사용되는 개방형 표준 프로토콜입니다.
OAuth 가 나오기 전에는 사용자의 아이디와 비밀번호를 직접 입력하거나 각 서비스 제공자마다 다르게 구현된 방식에 따라 인증을 진행해야했지만, OAuth 가 등장한 이후로는 하나의 통합된 프로토콜에 맞춰 다양한 서비스 제공자를 이용할 수 있게 되어 훨씬 편리해졌습니다. 인증은 물론 권한 허가까지 동시에 진행할 수 있다는 점도 큰 이점입니다.
OAuth 2.0은 OAuth1.0a와 비교하여 기능이 단순화되었고, Https 프로토콜을 지원하며, 다양한 인증방식을 지원하는 등 개선된 형태의 프로토콜을 지원합니다.
OAuth2.0의 인증방식은 클라이언트의 종류나 시나리오에 따라서 크게 4가지 정도로 구분되며 Authorization Code Grant, Implicit Grant, Password Credential Grant, Client Credentials Grant 등이 있습니다. 하지만 OAuth1.0a 버전과 가장 유사한 Implicit Grant 가 가장 많이 사용되는 됩니다.
OAuth2.0 에는 보통 세 분류의 주체가 있고 서로 상호작용하는 과정을 거칩니다. 예를 들어 모두싸인의 고객이 카카오로 로그인하기를 이용하여 모두싸인 서비스에 접근하고자 한다고 가정해봅시다. 이때 OAuth2.0에 따르면 아래와 같은 방식으로 인증절차가 진행됩니다.
사용자는 모두싸인에 접속한 뒤, 카카오로 로그인하기 버튼을 클릭합니다.
요청을 받은 모두싸인은 카카오 서버에 로그인을 요청합니다.
카카오 서버는 로그인 페이지를 제공합니다.
제공된 페이지에 사용자는 아이디와 비밀번호를 입력 후 로그인합니다.
서비스 제공자인 카카오 서버는 Authorization Code를 발급한 뒤, 사용자를 다시 모두싸인 페이지로 리다리엑트 시킵니다.
모두싸인은 Authorization Code를 이용해 Access Token 을 요청합니다.
서비스 제공자인 카카오 서버는 Access Token 을 발급합니다. 이때 모두싸인은 이 토큰을 저장합니다.
인증이 완료되고 카카오 로그인에 성공하면 고객은 모두싸인에 내정보보기 서비스를 요청합니다.
이때 모두싸인은 Access Token 과 함께 카카오 내정보보기 API를 호출합니다.
카카오 서버는 Access Token 을 검증한 뒤, 모두싸인에게 서비스를 제공합니다.
응답을 받은 모두싸인은 고객에게 서비스를 제공합니다.
OAuth2.0은 왜 필요한가
각 서비스 제공자별로 달랐던 인증방식을 하나로 통합하여 하나의 방식으로 여러 어플리케이션의 인증을 사용할 수 있게 해주어 개발상 편리합니다.
API를 인증함에 있어서 써드파티 어플리케이션에게 사용자의 비밀번호를 노출하지 않고 인증할 수 있습니다. 따라서 보안적으로도 이점이 있습니다.
OAuth1.0a 과 비교할 때, 인증방식이 다양하므로 웹 브라우저, 모바일 어플리케이션 등 다양한 시나리오에 대응할 수 있습니다.
OAuth1.0a 과 비교할 때, API 인증 서버가 리소스 서버와 분리되어 서비스의 확장성에도 보다 쉽게 대응할 수 있습니다.
OAuth1.0a 과 비교할 때, HTTPS 통신을 지원하므로 Signature 를 추가적으로 만들어 요청하지 않아도 된다는 점에서 테스트와 실행이 보다 쉬워졌습니다.
참고
Last updated