들어가기
oAuth는 인증을 위한 표준으로 이미 구글, 페이스북, 트위터 등에서 사용하고 방식이다. 국내에서도 Naver, Daum 등이 oAuth를 이용해서 인증을 하고 자사의 서비스들 사용할 수 있도록 하고 있다.
oAuth가 중요한 것은 인증을 통합할 수 있기 때문이다. 제3의 서비스에서 서비스를 만들었다고 해보자. 기존의 방식은 해당 서비스에서 사용자를 가입시키고 관리해야 한다. 사용자 정보가 서비스마다 분산되어 있기 때문에 다른 회사의 서비스( 구글 서비스 )와의 연동도 할 수 없다. oAuth를 통해서 인증을 하고 인증된 정보를 가지고 서비스를 통합 할 수 있다. 이제 같은 회사에서 만든 서비스가 아니라고 해도 서비스를 연동시켜서 또 다른 서비스를 만들게 되었다. 매쉬업을 통해서 서비스를 만들수 있는 것도 oAuth의 인증 방식을 사용 할 수 있기 때문이다.
이 문서에서는 oAuth 1.0을 기준으로 설명을 할 것이다. 최근에는 oAuth 2.0으로 많은 기업들이 전환을 하고 이제는 보안상의 문제와 약간의 미지한 부분들 때문에 oAuth 1.0이 쓰이지 않게 되었지만 기본적인 원리는 동일하기 때문에 oAuth 1.0을 설명하고 oAuth 2.0에 대해서도 잠시 언급을 할 것이다.
상세한 내용들은 구글이나 트위터들의 인증을 위한 문서를 따로 마련해 주고 있으니 참고항목에서 관련 URL들을 확인 할 수 있다.
용어
우선 oAuth에서 사용되는 용어를 살펴보도록 하자. 개념을 이해하는 데 용어를 아는 것을 중요하다.
- 서비스 프로바이더 (Service Provider)
- oAuth를 제공해주는 주체로 구글, 페이스북 등이 여기에 해당한다. 이들 업체는 사용자의 데이터를 가지고 있고 인증된 컨슈머에게 데이터를 제공한다.
- 사용자(User)
- 서비스 프로바이더에 계정을 가지고 있는 사용자로 서비스를 요청하는 초기 요청자이다. 모든 서비스의 시작은 사용자의 요청으로 부터 시작한다.
- 컨슈머(Consummer)
- oAuth 인증을 통해서 사용자 대신 서비스 프로바이더의 개인 데이터에 접근하려는 주체이다. 사용자는 컨슈머의 서비스를 통해서 서비스 프로바이더의 서비스를 이용할 수 있다. 제 3 서비스가 여기에 해당한다. 보통의 oAuth를 이용하려는 서비스가 이에 해당한다.
- 서비스(Service)
- oAuth 인증을 통해서 프로바이더의 사용자 데이터를 가져오는 행위를 서비스라 한다. 즉, oAuth을 이용하는 것을 프로바이더의 서비스를 이용하기 위한 것이다.
- 컨슈머 키(Consumer Key)
- 컨슈머를 구별하기 위한 키로 서비스 프로바이더를 통해서 발급된다. 개발자가 oAuth를 이용하기 위해서 처음으로 할 일은 이 컨슈머 키를 발급 받는 것이다. 보통 서비스 프로바이더의 개발자 사이트에서 발급한다. 컨슈머 키를 확인 소유권을 검증하기 위해서 컨슈머 비밀키(Cosunmer Secret)도 같이 발급이 된다.
- 요청토큰(Request Token)
- 사용자의 인증을 획득하는 과정에서 사용하게 되는 요청 키로 최종 목적인 접근 토큰을 획득할 때까지 임시로 사용된다.
- 접근 토큰(Access Token)
- oAuth의 전 과정은 이 접근 토큰을 얻기 위한 과정으로 서비스 프로바이더에 데이터를 요청할 때 사용될 사용자의 인증키이다. 이 키는 보통 서비스 기간이 있으면 정해진 기간 동안에만 사용이 가능하다. oAuth 2.0에는 이 키는 갱신할 수 있는 기능이 추가되었다.
- 시그너처(Signature)
- oAuth의 인증 과정에서 사용되는 요청을 검증하기 위한 검증 값으로 정해진 절차를 통해서 컨슈머가 생성을 해주어야 한다. 시그너처를 만드는 과정에 복잡하기 때문에 oAuth 2.0에서는 이를 개선했다.
- 보호 자원(Protected Resource)
- 서비스 프로바이더가 가지고 있는 사용자 데이터로 인증을 거친 이후에 사용할 수 있는 자원이다.
이상으로 oAuth에 사용되는 용어들을 알아보았다. 다음은 어떤 절차를 거치게 되는지 알아 볼 것이다.
절차
oAuth를 사용하기 위해서 3 주체들이 정보를 주고 받게 되는데 이들은 사용자, 컨슈머, 서비스 프로바이더이다.
<그림1> 3 주체간 인증 절차 ( 출처 : http://www.ibm.com/developerworks/web/library/wa-oauth1/ )
사용자, 컨슈머, 서비스 프로바이더라는 어려우니 좀 더 친근한 용어를 써보자. 사용자는 나이고 컨슈머는 MyGood.com이라고 하자. MyGood.com은 구글의 oAuth를 이용해서 로그인을 할 것이다. 그럼 이제 로그인을 하는 과정을 살펴보자. 그림과 같이 살펴보자. 그림은 일반적인 과정을 보여주는 것이기 때문에 아래 설명과 같이 이해을 해보자.
1. 내가 MyGood.com에 로그인을 요청한다.
내는 MyGood.com에 접속을 한다. 접속 화면에 “google 계정으로 접속”이라는 버튼이 있다고 가정해보자. 이 버튼을 사용자가 누른다. 사용자는 구글의 계정을 이용해서 MyGood.com을 로그인 할 것이다.
2. MyGood.com은 구글에 요청 토큰(Request Token)을 요청한다.
MyGood.com에서 요청을 받으면 request token을 구글에 요청한다. MyGood.com은 웹서비스 내부에서 서비스 프로바이더인 구글에 요청을 하게 된다.
3. 구글은 요청토큰을 발급해서 MyGood.com에 보낸다.
구글을 MyGood.com에서 보내온 요청에 따라서 요청 토큰을 발급한다. 이 토큰은 아직 인증을 거치지 않았다.
4~5. MyGood.com는 ID/PW 넣을 페이지로 redirect 시킨다.
MyGood.com이 요청토큰을 받으면 요청 토큰을 인증하기 위해서 페이지를 서비스 프로바이더에서 제공하는 페이지로 redirect하게 한다. 전환된 화면은 ID/PW를 넣을 수 있거나 이미 로그인이 되어 있다면 권한은 설정하는 페이지가 보일 것이다. 사용자는 이 페이지를 통해서 요청 토큰을 인증하게 된다. 이런 방식은 oAuth의 가장 큰 장점인데 컨슈머는 사용자의 ID/PW를 볼 수 없다는 것이다. ID/PW를 한 프로바이더에서 관리하는 것을 보안 측면에서 좋다. 단, 서비스 프로바이더를 절대적으로 믿어야 한다는 점이 남아있다.
6~7. 사용자가 ID/PW를 넣고 완료하면 다시 컨슈머로 돌아 온다.
정상적으로 로그인을 한 이후에 페이지 화면이 다시 컨슈머로 돌아 온다. 이 때 사용되는 것이 콜백 URL이다. 콜백 URL는 2번 과정에서 설정하게 된다. 혹은 컨슈머 키를 발급 받을때 설정 할 수도 있다. 어쨌든 제어권이 다시 컨슈머에게 돌아 왔다.
8~9. MyGood.com에서 접근 토큰(Access Token)을 요청한다.
이제 요청 토큰이 인증이 되었으니 접근 토큰을 요청한다.
9~12. access token이 들어오면 사용자 정보를 확인해서 로그인 처리를 한다.
접근 토큰을 얻으면 이제 사용자의 데이터에 접근할 수 있으니 필요한 데이터를 웹서비스 API를 통해서 조회해서 로그인 과정을 마무리한다.
이상이 oAuth을 사용하는 일반적인 플로우이다. 이는 사용하는 시스템이 웹으로 접근하는 경우에 해당한다. 웹이 아닌 CUI(콘솔)로 해야 한다면 어떨까? 이때는 위에서 살펴본것 처럼 자동으로 되지 않는다. 사용자의 개입이 필요하다. 콜백 URL 때문이다. 콜백 URL이 없으니 이부분은 사용자가 해주면 된다. 콜백 URL 대시 홈페이지에 보이는 PIN 번호를 보고 콘솔에 적어준다.
절차별 교환하는 Data
<그림2> 인증 절차 ( 출처 : http://oauth.net/core/1.0 )
<그림2>는 프로세스별로 어떤 데이터를 주고 받는지를 보여주고 있다. 앞에서 살펴본 과정을 보면서 어떤 데이터가 오가는지 보도록 하자. 상세한 설명은 생략하도록 하겠다. 혹시 자세한 쓰임을 알고 싶다면 스펙 문서를 보기 바란다.
oAuth 2.0 에서 변경된 것들
그럼 oAuth 2.0에서 변경된 것들은 어떤 것들이 있을까?
- 총 6가지의 각각 다른 시나리오에서 oAuth을 이용할 수 있는 방법을 제시
oAuth 1.0 에서는 주로 웹을 이용하기 때문에 웹에서 어떻게 oAuth을 사용할 수 있는지만 설명하고 있다. 물론 대안도 있지만 현재처럼 여러 상황 속에서 사용할 때를 고려하지는 못했다. 하지만 oAuth 2.0에서는 6개의 시나리오를 통해서 어떻게 oAuth사용할지 스펙에서 명시하고 있다. 좀 더 명확해졌다고 할 수 있다.
- access token을 갱신할 수 있는 기능 추가
기존 oAuth 1.0에서는 access token을 갱신 할 수 없어서 한번 access token을 얻으면 상당히 긴 기간을 추가적인 인증 없이 사용할 수 있었다. ( 페이스북은 6개월 이였다. ) oAuth 2.0에서는 refresh 할 수있는 기능이 추가되면서 access token이 짧아지도록 했다. 이 때문에 서비스를 만드는 입장에서는 불편한 점들이 많아져서 불만의 목소리도 있지만 보안 강화라는 측면에서 환영받는 측면도 있다.
- 보호 자원에 접속할 때는 HTTPS를 사용하도록 제약
보안안을 위해서 보호 자원을 접속할 때는 보안 채널을 사용하도록 강제하고 있다. TLS혹은 HTTPS를 사용해야 한다는 말이다.
아직 oAuth 2.0은 표준이 진행 중이다. 원래 표준을 만드는 것을 긴기간이 요구되는 작업이기 때문에 보통 기업들은 표준이 진행되는 중에 개발을 진행한다. oAuth 2.0도 이미 기업들은 실제로 자신들의 서비스에 적용을 하고 있다. 1.0과 2.0은 호환되지 않기 때문에 사용하려는 서비스의 표준을 살피고 되도록이면 2.0으로 개발을 진행하는 것이 좋다.
구현에 대해서
자~ 이제 구현 측면을 살펴보자. oAuth은 업계에서 만이 사용하는 기술이기 때문에 현재 많은 라이브러리들이 나와 있다.
oAuth를 사용하다는 것은 Consummer을 만드는 것이기 때문에 다음과 같은 것들이 필요하다.
-
Consummer key 받기 우선
oAuth사용할 서비시를 서비스 프로바이더에 등록해야 한다. 서비스 등록을 하면 컨슈머 키를 발급 받게 된다. 서비스 프로바이더는 이렇게 발급한 키를 가지고 어떤 서비스가 요청을 했는지 어떻게 정보까지 공개할 것인지 결정을 한다.
-
서비스 요청 웹서비스 개발
컨슈머 입장에서 oAuth을 이용하는 시작 점이다. 사용자가 서비스 프로바이더의 데이터를 요청 ( 로그인 등 )할 때 사용자는 이 URL로 요청을 하게 된다. 여기는 서비스 프로바이더에 request token을 요청하고 사용자에게 아이디/암호를 넣을 수 있는 서비스 프로아비더의 URL로 전환시켜준다.
-
callback 처리 웹 서비스 개발
사용자가 서시스 프로바이더에서 제공하는 페이지에 아이디/암호를 재대로 입력하면 프로바이더는 callback URL로 redirect시켜준다. 즉, oAuth의 인증 결과를 처리하는 웹 서비스이다.
이렇게 3가지를 개발하면 oAuth을 사용할 수 있다. oAuth 2.0도 위와 같이 3 부분을 해야 하는 것은 동일하다. 자세한 것을 사용하려는 서비스 업체의 문서를 확인하기 바란다.
구현에 사용된 소스들이 많이 있다. 우선 oAuth 1.0은 다음 사이트를 참조하면 된다. 언어별로 어떤 라이브러리를 어떻게 사용해야 하는지 잘 설명하고 있다.
oAuth 2.0은 구글이나 트위터의 문서에서 잘 설명하고 있다. oAuth는 표준이기 때문에 같은 API를 사용하 수 있다.
마무리
이상으로 oAuth에 대해서 간략하게 정리를 해보았다. oAuth는 이제 멈출 수 없는 흐름이 되었다. 구글, 페이북들은 이미 수십억명의 사용자를 확보하고 있다. 이런 업체들을 자사의 서비스를 다를 서비스 업체들이 쉽게 통합 할 수 있도록 하기 위해서 자사의 API를 공개하고 있다. 이 공개된 API를 사용하기 위해서는 oAuth를 해야 한다.
사용자 입장에서도 서비스를 이용하기 위해서 아이디를 새로 만들어야 하는 귀찮은 작업을 하려하지 않는다. 이런 환경 속에서 결국에는 구글과 같은 기존의 사용자를 많이 가지고 있는 업체를 이용해서 인증을 받는 서비스가 주류를 이룰것이다. ( 지금도 많은 업체들이 그렇게 하고 있다. )
이글을 통해서 oAuth에 대해서 쉽게 이해 했기를 바란다. 이 글에서 설명하지 못한 부분은 참고 문서를 참고해서 더 알아볼 수 있도록 하자.
참고
- 스펙
- 구현
- oAuth 설명
- oAuth에서 사용되는 기술
'보안개발 > 구글 OAuth 2.0 API' 카테고리의 다른 글
| Facebook 연동 - API Error Description: Invalid OAuth 2.0 Access Token (0) | 2015.04.07 |
|---|---|
| [OAuth]인증을 위한 오픈 스탠더드 프로토콜로 (0) | 2015.04.07 |
| OAuth 2.0 관련 정보 (0) | 2015.04.06 |
| 구글 OAuth 2.0 API 참조 링크 (0) | 2015.04.02 |
nineDeveloper
안녕하세요 현직 개발자 입니다 ~ 빠르게 변화하는 세상에 뒤쳐지지 않도록 우리모두 열심히 공부합시다 ~! 개발공부는 넘나 재미있는 것~!