OAuth 2.0 소개

OAuth 2.0 소개

이 글의 원문은 2010년 5월에 작성되었으며 OAuth 2.0은 현재 draft-25까지 작성되었습니다.

원문은 http://hueniverse.com/2010/05/introducing-oauth-2-0/ 에서 보실 수 있습니다.

역사

2주전, IEFT OAuth 워킹그룹은 OAuth 2.0프로토콜의 첫번째 초안을 발표했습니다. OAuth는 사용자가 그들의 비밀번호를 공유하지 않고 웹자원에 대해 써드파티 접근을 가능하게 해주는 보안 프로토콜 입니다.OAuth 1.0은 2007년 10월에 발표되었으며 빠르게 웹기반 접근 위임 업계표준으로 자리잡았습니다. 마이너 리비전(OAuth 1.0 Revision A)는 몇가지 보안취약점을 해결하고 2008년 6월에 발표되었습니다.OAuth 1.0는 RFC 5849로 출판되었습니다.

OAuth 2.0은 완전히 새로운 프로토콜 이며 이전버전과의 호환성을 제공하지 않습니다. 하지만, 전체적인 아키텍처와 개념은 이전 버전과 명맥을 유지하고 있습니다.

등장배경

많은 고급 자동차들은 발렛키를 가지고 있습니다. 이 특별한 키는 보통키와 달리 주차하기 위한 짧은 거리만을 운행할 수 있을뿐 트렁크를 연다거나 내장된 휴대전화를 거는등의 행위는 차단됩니다. 발렛키 아이디어는 매우 명확합니다. 당신은 특수키와 함께 당신 차에대한 제한된 접근권한을 주며, 다른 키로 모든것을 풀 수 있습니다.

웹이 성장하면서,더 많은 사이트들이 분산 서비스와 클라우드 컴퓨팅에 의존하고 있습니다.당신의 플릭커 사진들을 인화하는 사이트가 있으며, 소셜 네트워크는 친구를 찾기위해 구글 주소록을 사용합니다. 또는 써드파티 어플리케이션들이 다양한 서비스들의 API를 활용하기도 합니다.

문제는 이 어플리케이션들이 다른 사이트로 부터 사용자 데이터에 접근하려면 사용자명과 비밀번호를 물어봐야 한다는 것입니다. 이렇게 할경우 사용자의 비밀번호가 누군가에게 노출될 수 있습니다.(종종 같은 비밀번호를 온라인 뱅킹이나 타 사이트와 같이 쓰기도 합니다.) 또한, 이 어플리케이션은 그들이 원하는 모든 접근권한을 가지게 됩니다. 그들은 무엇이든지 할 수 있으며, 비밀번호를 바꾸기라도 한다면 사용자는 사이트를 이용할 수 없게 됩니다.

OAuth는 사용자가 써드파티 어플리케이션에게 비밀번호를 공유하지 않고 권한을 부여하는 방법을 제공합니다. 또한, 제한된 접근만 허가 합니다.(범위, 시간등)

예를들어,웹 사용자는(자원 소유자)프린팅 서비스의 사용자명과 비밀번호를 공유하지 않고, 사진 공유 서비스(서버)에 저장된 개인사진에 대해서만 프린팅 서비스(클라이언트)에 대해 접근이 허가됩니다. 대신, 사진 공유 서비스에서 프린팅 서비스가 위임한 신임장에 의해 직접 인증을 받습니다.

새로운 초안은 목적과 요구사항에 대해 폭넓은 기업들(Yahoo, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, Google)의 참여를 통해 1년에 걸친 논의에 의해 제정되었습니다. OAuth는 오픈 기술 채용에 적극적으로 움직여 왔으며 2.0도 예외는 아닙니다. Facebook과 Twitter는 이미 첫번째 초안이 공식적으로 발표되기 이전에도 지원을 약속했습니다.

왜 새로운 버전인가?

OAuth 1.0은 두개의 지적 재산권이 존재하는 프로토콜에 기반하고 있었습니다. Flickr의 Auth API와 구글의 AuthSub 입니다. 그 결과 실제 구현 경험에 기반한 최상의 솔루션을 얻을 수 있었습니다. 3년 이상 이 프로토토콜을 사용하면서 커뮤니티는 OAuth 1.0에 의해 제한 또는 혼돈될 수 있는 3가지 주요 사안에 대해 충분히 다시 고려하였습니다.

인증과 서명

OAuth 1.0 구현체의 주요 폐인은 스펙의 암호화 요구사항의 복잡성으로 인해 발생하였습니다. 사실, 원래 스펙은 상세히 적시되지 않았을 뿐만 아니라 RFC 5849에서 새로이 기술되었습니다. OAuth 1.0은 아직 클라이언트에서 사용하기에 사소한것 까지 명문화 하지 않고 있습니다. 단순한 암호화 체계를 사용함으로 인해 간편하고 쉬운 방법을 제공하지 못한것은 OAuth의 아쉬운점 입니다.

예를들어, 개발자들은 그들의 사용자명과 비밀번호를 이용해 빠르게 Twitter스크립트를 작성할 수 있습니다. OAuth로 이동하면서, 개발자들은 한줄의 cURL스크립트를 실행하기 위해 라이브러리를 찾고, 설치하고, 설정하는데 집중하게 되었습니다.

사용자 경험과 대안 토큰 발행 옵션

OAuth는 두개의 주요 부분을 포함하고 있습니다:사용자에게 접근을 허가할지 질문하여 토큰을 획득하고,이 토큰을 사용하여 보호된 자원에 접근합니다.억세스 토큰을 획득하는 방법을 플로우(flows)라고 부릅니다. OAuth 1.0은 3가지 플로우로 시작되었습니다:웹기반 어플리케이션,데스크탑 어플리케이션,그리고 모바일 또는 제한된 디바이스.하지만,스펙이 진화함에 따라,세가지 플로우는 하나(문서)로 합쳐졌습니다. 사례에 따르면 플로우는 웹기반 어플리케이션에서는 잘 작동하지만 다른 환경에서는 그렇지 못합니다.

Twitter와 같은 더 많은 사이트들이 OAuth를 사용하면서 개발자들은 OAuth에 의해 매우 제한적이고 형편없는 사용자 경험의 한가지 플로우만 제공되는것을 깨닳았습니다.반면, 페이스북 커넥트는 웹 어플리케이션, 모바일 장치, 게임 콘솔을 위한 풍부하고 적절한 플로우셋을 제공했습니다.

성능 확장

대형 프로바이더들이 OAuth를 사용하기 시작할때,커뮤니티는 이 프로토콜이 확장적이지 않다는 것을 깨닳았습니다. 이것은 여러 단계에 걸쳐 상태 관리가 필요하며, 임시로 신임장을 기억해야 했으며, 종종 사용되지 않음에도 폐기되지 않았으며, 보통 오랫동안 신임장을 발급한 상태로 유지되는것을 필요로 했습니다. 이것은 덜 보안적이며 관리하기 어려웠습니다. (데이터센터간 동기화 역시)

추가적으로, OAuth 1.0은 클라이언트 신임장과 토큰 비밀번호 두가지 모두를 사용합니다. 이것은 분리를 더욱 어렵게 합니다.

그래서 뭐가 새로운데?

다음은 OAuth 2.0에서 이용 가능한 새로운 기능중 일부입니다.

6가지 새로운 플로우

  • 사용자 에이전트 플로우 – 클라이언트가 사용자 에이전트쪽에서 실행됩니다. (보통 웹브라우저임)

  • 웹서버 플로우 – 클라이언트가 HTTP요청을 통해 접근할 수 있는 웹서버 어플리케이션의 일부입니다. 이것은 OAuth 1.0에 의해 제공된 더 단순한 버전의 플로우 입니다.

  • 장치 플로우 – 제한된 장치상에서 실행되기에 적합합니다. 하지만, 엔드유저는 다른 컴퓨터나 장치에서 브라우저에 별도로 접근할 수 있습니다.

  • 사용자명과 비밀번호 플로우 – 사용자는 클라이언트가 신임장을 핸들링하는것은 신뢰하지만 클라이언트가 사용자의 사용자명과 비밀번호를 저장하는것은 탐탁치 않은경우에 사용됩니다. 이 플로우는 사용자와 클라이언트간에 높은 등급의 신뢰성이 보장될 경우에만 적합합니다.

  • 클라이언트 신임장 플로우 – 클라이언트는 억세스 토큰을 획득하기 위해 신임장을 사용합니다. 이 플로우는 2-legged 시나리오에 대해 지원합니다. (http://cakebaker.42dh.com/2011/01/10/2-legged-vs-3-legged-oauth/ 참고.)

  • 어써션 플로우 – 클라이언트는 SAML과 같은 신임장을 인증서버에 제공하여 억세스 토큰을 교환합니다.

위와 같은 다양한 플로우들을 사용하여 네이티브 어플리케이션들을 구현할 수 있습니다.

토큰 운반자

OAuth 2.0은 인증을 위해 암호화로 부터 자유로운(암호화 되지않은) 옵션을 제공합니다. 이것은 존재하는 쿠키 인증 아키텍처에 기반합니다. HMAC과 토큰 시크릿을 사용한 서명된 요청을 발송하는 대신, 토큰 스스로가 시크릿으로서 HTTPS를 통해 보내집니다. 이것은 cURL및 다른 단순한 스크립팅 도구를 사용해 API호출을 만드는것을 허락합니다.

단순화된 서명

서명 지원은 파싱, 인코딩, 그리고 파라미터의 정렬을 위해 매우 단순해 졌습니다. 또한, 두개 대신 하나의 시크릿을 사용합니다.

단기유효 토큰과 장기유효 권한들

긴 시간동안 유효한 토큰을 발급하는 대신(보통 1년 또는 무제한 수명), 서버는 단기유효 억세스 토큰을 발급할 수 있으며 장기간 토큰을 재활용 할 수 있습니다. 이것은 클라이언트가 사용자가 관여할 필요 없이 새로운 억세스 토큰을 획득하는것을 허락합니다. 하지만 억세스 토큰은 제한적입니다. 이 기능은 Yahoo의 BBAuth 프로토콜로부터 차용되었습니다. 그리고 다음에 OAuth 1.0 세션확장에도 사용되었습니다.

역할의 분리

OAuth 2.0은 인가서버의 역할을 리소스 서버 API호출시에 사용자 권한획득과 토큰발급을 위한 목적으로 구분합니다.

언제 완성되나요?

OAuth 2.0은 현재 IETF OAuth 워킹그룹에 의해 개발중입니다. 최종 드래프트는 안정적인 상태로 볼 수 있습니다만 많은 기능들이 변경되거나 추가될 수 있습니다. 부분적 지원은 이미 Facebook과 Twitter로부터 가능합니다. 마지막 스펙은 올해 말쯤에나 가능할 것으로 보입니다.

Advertisements

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중