다음의 웹 페이지를 번역한 것 입니다.
http://hueniverse.com/2010/05/introducing-oauth-2-0/
번역 내용 중 오역이 있을 수 있습니다.
2주전 IETF OAuth 워킹 그룹은 OAuth 2.0 프로토콜의 첫번째 draft를 배포하였습니다. OAuth는 비밀번호의 공유 없이 그들의 웹 리소스에 사용자가 써드 파티 접근 허가를 가능하게 해주는 하나의 보안 프로토콜 입니다. OAuth 1.0은 2007년 12월에 배포되었고, 웹 기반 접근 대안으로써 빠르게 산업 표준화 되어갔습니다. 마이너 교정은 (OAuth 1.0 리비전 A) 보안 문제를 픽스하여 2008년 6월에 배포 되었하였습니다. 2010년 4월에 OAuth는 RFC 5849로서 배포 되었습니다.
OAuth 2.0은 완벽한 새로운 프로토콜이고, 이전 버전과 하위 호환되지 않지만 전체적인 아키텍처와 이전 버전에서 확립된 접근법을 그대로 간직하고 있으며 여전히 많은 적용 요소들을 유지하고 있습니다.
"많은 럭셔리 자동차는 주차키를 가지고 있습니다. 이것은 하나의 특별한 키로 주차만을 위해 제공됩니다. 이 특별한 키는 여러분이 가지고 있는 일반적인 키와 같지 않은데 짧은 거리에 대한 운전만 허용하고 전화나 트렁크에 대한 접근은 허락하지 않습니다. 주차키로 이러한 제한을 하는 것은 매우 영리한 아이디어 입니다. 여러분이 그 외에 다른 잠겨있지 않은 것들을 사용할 때 하나의 특별한 키가 자동차에 대한 제한된 접근을 제공할 것입니다.
웹이 성장함에 따라 더 많은 사이트가 분산 서비스와 클라우딩 컴퓨팅에 의존합니다.: 여러분의 플리커 사진을 인화하는 포토랩, 친구를 찾기 위해 구글 주소록을 사용하는 소셜 네트워크나 다중 서비스로 API를 활용하는 써드 파티 응용 프로그램들이 그것 입니다.
문제는 사용자 이름과 비밀번호를 묻기 위해선 다른 사이트에서 사용자 데이터에 접근하기 위한 응용 프로그램이 고려되어야 한다는 것 입니다. 그리고 이 응용 프로그램을 통해 내가 아닌 다른 누군가에게 사용자 암호가 노출될 수 있다는 겁니다. - 종종 온라인 뱅킹이나 다른 사이트에서 사용되는 비밀번호와 같은 것들 - 이것은 그들이 원하는 대로 제한 없이 접근할 수 있는 방법을 제공합니다. 그들은 사용자를 잠그거나 비밀번호를 변경하는 어떤 행위든 할 수 있습니다.
OAuth는 나의 비밀번호 공유 없이 그들이 가진 리소스에 접근하여 이용이 가능하도록 하는 써드 파티 접근 허가에 대한 사용자를 위한 메서드를 제공합니다.
예를 들어서 하나의 웹 사용자는(리소스 오너) 프린팅 서비스에 그녀의 사용자 이름과 비밀번호 없이 포토 공유 서비스(서버)에 저장된 그녀의 개인적 사진에 접근하여 프린팅 서비스(클라이언트)를 허가할 수 있습니다. 대신에 그녀는 위임-특별 증명을 발행하는 것으로 사진 공유 서비스에 직접적으로 인증하게 됩니다."
새로운 draft는 야후, 페이스북, 세일즈포스, 마이크로소프트, 트위터, Deutsche Telekom, Intuit, 모질라와 구글을 포함하는 넓은 범위의 회사들이 참가함으로써 프로토콜에 대한 목표와 요구들에 대한 오랜 기간의 요구를 표현하였습니다. OAuth는 개방형 기술로 급속하게 채택되었으며 2.0도 예외는 아닙니다. 페이스북과 트위터는 첫 초안이 공식적으로 배포되기 전에 이미 지원을 발표하였습니다.
왜 새로운 버전인가?
OAuth 1.0은 플리커 API나 구글 AuthSub와 같은 대부분 기존의 독점적인 프로토콜을 기반이었습니다. 그 결과 실제적인 구현 경험을 기반으로 최고의 솔루션을 표현하게 되었습니다. 프로토콜로서 사용된 3년 이상의 경험을 토대로 커뮤니티는 OAuth 1.0이 어디서 제한되고 혼동되는지 충분히 배웠고, 3가지 주요 영역 내에서 프로토콜을 개선하는 것에 대해 배웠습니다.
인증 및 서명
OAuth 1.0 구현 시도에 대한 대부분의 실패는 암호화 요구사항이 복잡하기 때문입니다. 실제로 원래 사양은 도움이 되지 않았습니다. 심지어 새롭게 출간된 RFC 5849로써 OAuth는 여전히 클라이언트 쪽에서 사용이 쉽지 않았습니다. 단순한 암호 사용을 위해 편리하고 쉬운 제공을 하지 못한 건 OAuth의 심각한 실수 였습니다.
예를 들어 개발자는 그들의 사용자 이름과 비밀번호를 사용하여 트위터 스크립트를 재빠르게 작성할 수 있습니다. 이들 개발자들은 cURL 스크립트의 단일 라인으로 검색, 인스톨, 그리고 설정 라이브러리를 이용할 수 있습니다.
사용자 환경과 대체 토큰 발행 옵션
OAuth는 2개의 주요 부분을 포함합니다.: 접속 허가를 위해 사용자에게 토큰 취득을 요구하고 보호된 리소스에 접근하기 위해 토큰을 사용합니다. 액세스 토큰을 얻기 위한 방법들을 흐름이라고 부릅니다. OAuth 1.0은 3개의 흐름으로 시작됩니다.: 웹 기반 응용 프로그램, 데스크 탑 클라이언트, 모바일과 제한된 디바이스 그러나 사양이 진화하여 3가지 흐름은 모든 3가지 클라이언트 유형을 제공하는 하나로 통합 되었습니다. 실제로 이러한 흐름은 웹 기반 응용 프로그램에서는 잘 작동하지만 그 외에는 열악한 경험을 제공합니다.
특히 트위터와 같은 더 많은 사이트들이 OAuth를 사용하기 시작 했습니다. 개발자들은 OAuth가 제공하는 제한된 흐름과 고급스럽지 못한 경험을 바탕으로 만들어지게면서 실현 되었습니다.
반면에 페이스북 커넥트는 웹 응용 프로그램, 모바일 기기, 그리고 게임기에 적합한 풍부한 집합을 제공합니다.
실적 규모
거대한 업체들이 OAuth를 사용하기 시작했을 때 커뮤니티들은 OAuth가 잘 확장되지 않는다는 것을 깨달았습니다. 그것은 여러 단계에 걸쳐 상태 관리가 필요하다는 것과 미사용시 폐기하는 것 보다 임시 자격 증명을 발급하는 것 그리고 일반적으로 덜 안전하고 더 어려운 관리가 필요한 오래 지속되는 자격 증명 발급이 필요했습니다.(그리고 데이터 센터와 동기화 되는 것)
추가적으로 OAuth 1.0은 보호된 자원 종점의 유효성 검사를 위해 클라이언트 자격 증명에 접근해야 합니다.
거대한 공급자의 일반적인 아키텍처는 중앙 서버가 자격 증명을 발급하고 분산 서버는 API 호출을 위해 사용됩니다.
OAuth 1.0은 자격증명시 클라이언트 자격증명과 토큰 자격증명 양쪽 모두를 사용하여 분리를 어렵게 합니다.
무엇이 새로워 졌을까?
- OAuth2.0에서 새롭게 이용할 수 있는 것들의 세부 집합은 다음과 같다.
- 6개의 새로운 흐름
- 사용자-에이전트-흐름: 사용자 내부에서 실행되는 클라이언트(일반적으로 웹 브라우저)
- 웹-서버-흐름: HTTP요청을 이용해 웹서버를 응용 프로그램을 호출하는 클라이언트. 이것은 OAuth 1.0에서 제공되는 간단한 버전이다.
- 디바이스 흐름: 제한된 디바이스 상에서 클라이언트가 실행하기에 적당. 그러나 최종 사용자는 또 다른 컴퓨터나 디바이스 상에서 하나의 브라우저에 접근하기 위해 별도로 가져야 한다.
- 사용자 이름과 비밀번호 흐름: 사용자가 클라이언트 자격 증명 처리를 위해 신뢰하는 케이스에서 사용된다. 그러나 사용자의 이름과 비밀번호를 저장하는 것을 클라이언트는 여전히 원하지 않는다.
- 클라이언트 자격증명 흐름: 클라이언트는 액세스 토큰을 얻기 위해 자격 증명을 사용한다. 이 흐름은 2-다리 시나리오로 잘 알려진 것을 지원합니다.
- 주장 흐름: 클라이언트에 액세스 토큰에 대한 교환을 위해 인증 서버에 SAML(보안주장표현언어)의 주장과 같은 주장을 선물한다.
네이티브 응용 프로그램 지원(데스크탑이나 모바일 디바이스에서 실행되는 응용 프로그램)은 위의 흐름을 사용하여 구현할 수 있습니다.
- 무기명 토큰
- OAuth 2.0은 기존의 쿠키 기반 인증 지원을 위해 암호화를 옵션을 제공한다.
- HMAC와 토큰 시크릿을 사용하여 서명된 요청을 보내는 대신에 토큰 그 자신은 HTTP를 통해 시크릿을 보낸다. 이것은 요청이나 서명에 대한 표준화 없이 cURL이나 간단한 스크립트 도구를 이용한 API 호출을 허가합니다.
간소한 서명
서명 지원은 특별한 파싱, 인코딩, 파라미터 정렬 등을 제거해 간소화 시켰습니다. 이것은 또한 2가지가 아닌 한가지 시크릿을 사용합니다.
수명이 긴 허가와 함께 수명이 짧은 토큰
오래 지속되는 토큰 문제 대신에 서버는 짧은 수명을 가지는 액세스 토큰과 긴 수명을 가지는 새로고침 토큰이 문제가 될수 있다. 이것은 사용자를 다시 포함할 필요 없이 새로운 액세스 토큰을 취득하기 위해 클라이언트를 허가한다. 그러나 액세스 토큰이 제한되어 있다. 이것의 특징은 야후의 BBAuth 프로토콜과 OAuth 1.0 세션 확장에 채용되어져 있다.
규칙의 분리
OAuth 2.0은 사용자 승인 획득에 대한 인증서버와 API 호출을 처리하는 리소스 서버에서의 토큰 문제를 분리합니다.
그것은 언제 오나요?
OAuth 2.0은 IETF OAuth 워킹 그룹이 개발한게 현재 입니다. 마지막 드래프트는 안정을 추구하지만 많은 특징들이 추가되거나 제거 되었습니다. 부분 지원은 페이스북이나 트위터로에서 이미 사용할 수 있습니다. 마지막 명세는 올해 말까지 예상됩니다.
|
요약 |
|
|
'Social' 카테고리의 다른 글
| OAuth 2.0 소개 (0) | 2012/05/14 |
|---|---|
| 4.[Facebook] Facebook for Websites(3) (0) | 2012/04/26 |
| 3.[Facebook] Facebook for Websites(2) (0) | 2012/04/25 |
| 2.[Facebook] Facebook for Websites(1) (0) | 2012/04/13 |
| 1.[Facebook] Getting Started (0) | 2012/04/08 |






댓글을 달아 주세요