OAuth 1.0a 이해

Security/OAuth 2013. 12. 29. 15:06


OAuth와 춤을 개발자Tip

2012.03.14 18:04

  

NHN 소셜게임서비스팀 오창훈

최근의 인터넷 서비스는 그 자체가 SaaS(Software as a Service)의 형태입니다. 서비스 중에서 사용자가 일부 필요한 것만 사용할 수 있게 한다는 것입니다. Facebook이나 트위터가 세상에 널리 퍼지게된 이유 중에 하나가 외부 서비스에서도 Facebook가 트위터의 일부 기능을 사용할 수 있게 한 것입니다. 외부 서비스와 연동되는 Facebook이나 트위터의 기능을 이용하기 위해 사용자가 반드시 Facebook이나 트위터에 로그인해야 하는 것이 아니라, 별도의 인증 절차를 거치면 다른 서비스에서 Facebook과 트위터의 기능을 이용할 수 있게 되는 것입니다. 이런 방식은 Facebook이나 트위터 같은 서비스 제공자뿐만 아니라 사용자와 여러 인터넷 서비스 업체 모두에 이익이 되는 생태계를 구축하는데 기여하게 될 것입니다.

이 방식에서 사용하는 인증 절차가 OAuth입니다. 이 기사에서는 OAuth의 탄생 배경과 OAuth 1.0의 인증 과정에 대해 간략하게 설명합니다.

  • OAuth의 탄생과 사용

    • OAuth는 인증을 위한 오픈 스탠더드 프로토콜로, 사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 애플리케이션(데스크톱, 웹, 모바일 등)에서도 사용할 수 있게 한 것이다.

    OAuth의 탄생 이전에도 다른 애플리케이션에 사용자의 아이디와 암호가 노출되지 않도록 하면서 API 접근 위임(API Access Delegation)이 가능한 여러 인증 방법이 있었다. Google과 Yahoo!, AOL, Amazon 등에서는 각각의 인증 방식을 제작하여 사용했다.

    OAuth 1.0이 나온 때는 2007년이며, 이후 보안 문제를 해결한 수정 버전인 OAuth 1.0 revision A 가 2008년에 나왔다.

    OAuth의 시작은 2006년에 트위터의 개발자와 소셜 북마크 서비스인 Gnolia의 개발자가 만나 인증 방식을 논의한 때부터였다. 두 회사의 개발자들은 그때까지 API 접근 위임에 대한 표준안이 없다는 것을 알았다. 그래서 2007년 4월 인터넷에 OAuth 논의체를 만든 뒤 OAuth드래프트 제안서를 만들어 공유했다. 그 뒤에 이 활동을 지지하는 사람이 생기게 되었고, 2008년 IETF 모임(73회, 미네소타에서 개최)에서 OAuth가 IETF 표준안으로 관리되야 하는 가에 대한 논의가 있었다. 그리고 2010년에 OAuth 1.0 프로토콜 표준안이 RFC5849로 발표되었다.

    2007년에 나온 OAuth 1.0은 비공식 논의체에 의해 최초로 만들어진 것이고, 2010년 IETF OAuth 워킹그룹에 의해 이 프로토콜이 IETF 표준 프로토콜로 발표된 것이다.

    현재 나와 있는 OAuth 2.0은 드래프트 단계에 있는 것으로, IETF OAuth 워킹그룹이 주축이 되어 만든 것이다. OAuth 2.0은 OAuth 1.0과 호환되지 않지만, 인증 절차가 간략하다는 장점이 있다. 그래서 아직 최종안이 나오지 않았음에도 여러 인터넷 서비스에서 OAuth 2.0을 사용하고 있다. 다음 표는 대표적인 인터넷 서비스 기업에서 사용하는 OAuth의 버전을 정리한 것이다.

    표 1 인터넷 서비스 기업이 사용하는 OAuth 버전

    인터넷 서비스 기업

    OAuth 버전

    Facebook

    2.0

    Foursquare

    2.0

    Google

    2.0

    Microsoft (Hotmail, Messenger, Xbox)

    2.0

    LinkedIn

    2.0

    Daum(티스토리

    2.0

    NHN (오픈API)

    1.0a

    Daum(요즘, 오픈API)

    1.0a

    MySpace

    1.0a

    Netflix

    1.0a

    트위터

    1.0a

    Vimeo

    1.0a

    Yahoo!

    1.0a

  • OAuth와 로그인

    • OAuth와 로그인은 반드시 분리해서 이해해야 한다. 일상 생활을 예로 들어 OAuth와 로그인의 차이를 설명해 보겠다.

    사원증을 이용해 출입할 수 있는 회사를 생각해 보자. 그런데 외부 손님이 그 회사에 방문할 일이 있다. 회사 사원이 건물에 출입하는 것이 로그인이라면 OAuth는 방문증을 수령한 후 회사에 출입하는 것에 비유할 수 있다.

    다음과 같은 절차를 생각해 보자.

  • 나방문씨(외부 손님)가 안내 데스크에서 업무적인 목적으로 김목적씨(회사 사원)를 만나러 왔다고 말한다.
  • 안내 데스크에서는 김목적씨에게 나방문씨가 방문했다고 연락한다.
  • 김목적씨가 안내 데스크로 찾아와 나방문씨의 신원을 확인해 준다.
  • 김목적씨는 업무 목적과 인적 사항을 안내 데스크에서 기록한다.
  • 안내 데스크에서 나방문 씨에게 방문증을 발급해 준다.
  • 김목적씨와 나방문씨는 정해진 장소로 이동해 업무를 진행한다.

    • 위 과정은 방문증 발급과 사용에 빗대어 OAuth 발급 과정과 권한을 이해할 수 있도록 한 것이다. 방문증이란 사전에 정해진 곳만 다닐 수 있도록 하는 것이니, '방문증'을 가진 사람이 출입할 수 있는 곳과 '사원증'을 가진 사람이 출입할 수 있는 곳은 다르다. 역시 직접 서비스에 로그인한 사용자와 OAuth를 이용해 권한을 인증받은 사용자는 할 수 있는 일이 다르다.

    OAuth에서 'Auth'는 'Authentication'(인증)뿐만 아니라 'Authorization'(허가) 또한 포함하고 있는 것이다. 그렇기 때문에 OAuth 인증을 진행할 때 해당 서비스 제공자는 '제 3자가 어떤 정보나 서비스에 사용자의 권한으로 접근하려 하는데 허용하겠느냐'라는 안내 메시지를 보여 주는 것이다. 다음의 화면 두 개는 각각 네이버와 미투데이에 접근 권한 요청이 있음을 알려 주는 화면이다. 미투데이의 경우에는 OAuth 인증 방식을 사용하지 않지만 인증 절차에 대한 예시 정도로 생각해 주기 바란다.

    o03.png

    그림 1 네이버 OAuth 접근 권한 요청 화면

    o01.png

    그림 2 미투데이 접근 권한 요청 화면

  • OpenID와 OAuth

    • OpenID도 인증을 위한 표준 프로토콜이고 HTTP를 사용한다는 점에서는 OAuth와 같다. 그러나 OpenID와 OAuth의 목적은 다르다.

    OpenID의 주요 목적은 인증(Authentication)이지만, OAuth의 주요 목적은 허가(Authorization)이다. 즉, OpenID를 사용한다는 것은 본질적으로 로그인하는 행동과 같다. OpenID는 OpenID Provider에서 사용자의 인증 과정을 처리한다. Open ID를 사용하는 여러 서비스(Relying Party)는 OpenID Provider에게 인증을 위임하는 것이다.

    물론 OAuth에서도 인증 과정이 있다. 가령 Facebook의 OAuth를 이용한다면 Facebook의 사용자인지 인증하는 절차를 Facebook(Service Provider) 처리한다. 하지만 OAuth의 근본 목적은 해당 사용자의 담벼락(wall)에 글을 쓸 수 있는 API를 호출할 수 있는 권한이나, 친구 목록을 가져오는 API를 호출할 수 있는 권한이 있는 사용자인지 확인하는 것이다.

    OAuth를 사용자 인증을 위한 방법으로 쓸 수 있지만, OpenID와 OAuth의 근본 목적은 다르다는 것을 알아야 한다.

  • OAuth Dance, OAuth 1.0 인증 과정

    • OAuth를 이용하여 사용자를 인증을 하는 과정을 OAuth Dance라고 한다. 두 명이 춤을 추듯 정확하게 정보를 주고받는 과정을 재미있게 명명한 것이다.

    OAuth를 이해하려면 몇 가지 용어를 먼저 알아 두어야 한다. 다음 표에 OAuth의 대표 용어를 정리해 보았다.

    표 2 OAuth 1.0 대표 용어

    용어

    설명

    User

    Service Provider에 계정을 가지고 있으면서, Consumer를 이용하려는 사용자

    Service Provider

    OAuth를 사용하는 Open API를 제공하는 서비스

    Consumer

    OAuth 인증을 사용해 Service Provider의 기능을 사용하려는 애플리케이션이나 웹 서비스

    Request Token

    Consumer가 Service Provider에게 접근 권한을 인증받기 위해 사용하는 값. 인증이 완료된 후에는 Access Token으로 교환한다.

    Access Token

    인증 후 Consumer가 Service Provider의 자원에 접근하기 위한 키를 포함한 값

    다음은 OAuth 인증 과정을 그림으로 표현한 것이다.

    o02.png

    그림 3 OAuth 1.0a 인증 과정(원본 출처: http://oauth.net/core/diagram.png)

    OAuth 인증 과정을 앞에서 설명한 회사 방문 과정과 연결하면 다음 표와 간다.

    표 3 회사 방문 과정과 OAuth 인증 과정

     

    회사 방문 과정

    OAuth 인증 과정

    1.

    나방문씨가 안내 데스크에서 업무적인 목적으로 김목적씨를 만나러 왔다고 말한다.

    Request Token의 요청과 발급

    2.

    안내 데스크에서는 김목적씨에게 나방문씨가 방문했다고 연락한다.

    사용자 인증 페이지 호출

    3.

    김목적씨가 안내 데스크로 찾아와 나방문씨의 신원을 확인해 준다.

    사용자 로그인 완료

    4.

    김목적씨는 업무 목적과 인적 사항을 안내 데스크에서 기록한다.

    사용자의 권한 요청 및 수락

    5.

    안내 데스크에서 나방문 씨에게 방문증을 발급해 준다.

    Access Token 발급

    6.

    김목적씨와 나방문씨는 정해진 장소로 이동해 업무를 진행한다.

    Access Token을 이용해 서비스 정보 요청

    위의 표에 따르면, Access Token은 방문증이라고 이해할 수 있다. 이 방문증으로 사전에 허락된 공간에 출입할 수 있다. 마찬가지로 Access Token을 가지고 있는 Consumer는 사전에 호출이 허락된 Service Provider의 오픈 API를 호출할 수 있는 것이다.

  • Request Token

    • OAuth에서 Consumer가 Request Token 발급을 요청하고 Service Provider가 Request Token을 발급하는 과정은 "저 나방문입니다. 김목적씨를 만날 수 있을까요?"라고 말하는 절차에 비유할 수 있다.

    Request Token을 요청하는 Request 전문을 살펴보자. 다음은 네이버의 OAuth API로 Request Token을 요청하는 예이다.

    ?
    1
    2
    3
    4
    GET /naver.oauth?mode=req_req_token&oauth_callback=http://example.com/OAuthRequestToken.do&oauth_consumer_key=WEhGuJZWUasHg&oauth_nonce=zSs4RFI7lakpADpSsv&oauth_signature=wz9+ZO5OLUnTors7HlyaKat1Mo0=&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1330442419&oauth_version=1.0 HTTP/1.1
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive
    Host: nid.naver.com

    보기 쉽도록 위의 내용을 아래와 같이 매개변수를 기준으로 정리했다.

    ?
    1
    2
    3
    4
    5
    6
    7
    8
    GET http://nid.naver.com/naver.oauth?mode=req_req_token&
    oauth_callback=http://example.com/OAuthRequestToken.do&
    oauth_consumer_key=WEhGuJZWUasHg&
    oauth_nonce=zSs4RFI7lakpADpSsv&
    oauth_signature=wz9+ZO5OLUnTors7HlyaKat1Mo0=&
    oauth_signature_method=HMAC-SHA1&
    oauth_timestamp=1330442419&
    oauth_version=1.0 HTTP/1.1

    Request Token 발급 요청 시 사용하는 매개변수는 다음 표와 같다.

    표 4 Request Token 발급 요청 시 사용하는 매개변수

    매개변수

    설명

    oauth_callback

    Service Provider가 인증을 완료한 후 리다이렉트할 Consumer의 웹 주소. 만약 Consumer가 웹 애플리케이션이 아니라 리다이렉트할 주소가 없다면 소문자로 'oob'(Out Of Band라는 뜻)를 값으로 사용한다.

    oauth_consumer_key

    Consumer를 구별하는 키 값. Service Provider는 이 키 값으로 Consumer를 구분한다.

    oauth_nonce

    Consumer에서 임시로 생성한 임의의 문자열. oauth_timestamp의 값이 같은 요청에서는 유일한 값이어야 한다. 이는 악의적인 목적으로 계속 요청을 보내는 것을 막기 위해서이다.

    oauth_signature

    OAuth 인증 정보를 암호화하고 인코딩하여 서명 값. OAuth 인증 정보는 매개변수 중에서 oauth_signature를 제외한 나머지 매개변수와 HTTP 요청 방식을 문자열로 조합한 값이다. 암화 방식은 oauth_signature_method에 정의된다.

    oauth_signature_method

    oauth_signature를 암호화하는 방법. HMAC-SHA1, HMAC-MD5 등을 사용할 수 있다.

    oauth_timestamp

    요청을 생성한 시점의 타임스탬프. 1970년1월 1일 00시 00분 00초 이후의 시간을 초로 환산한 초 단위의 누적 시간이다.

    oauth_version

    OAuth 사용 버전. 1.0a는 1.0이라고 명시하면 된다.

  • oauth_signature 만들기

    • OAuth 1.0에서는 oauth_signature를 생성하는 것이 가장 까다로운 단계이다. 당연히 Consumer와 Service Provider가 같은 암호화(signing) 알고리즘을 이용하여 oauth_signature를 만들어야 한다.

    oauth_sinature는 다음과 같이 네 단계를 거쳐 만든다.

  • 1. 요청 매개변수를 모두 모은다.

    • oauth_signature를 제외하고 'oauth_'로 시작하는 OAuth 관련 매개변수를 모은다. POST body에서 매개변수를 사용하고 있다면 이 매개변수도 모아야 한다.

  • 2. 매개변수를 정규화(Normalize)한다.

    • 모든 매개변수를 사전순으로 정렬하고 각각의 키(key)와 값(value)에 URL 인코딩(rfc3986)을 적용한다. URL 인코딩을 실시한 결과를 <key>=<value> 형태로 나열하고 각 쌍 사이에는 &을 넣는다. 이렇게 나온 결과 전체에 또 URL 인코딩을 적용한다.

  • 3. Signature Base String을 만든다.

    • HTTP method 명(GET 또는 POST), Consumer가 호출한 HTTP URL 주소(매개변수 제외), 정규화한 매개변수를 '&'를 사용해 결합한다. 즉 '[GET|POST] + & + [URL 문자열로 매개변수는 제외] + & + [정규화한 매개변수]' 형태가 된다. 이 예제에서는 'http://nid.naver.com/naver.oauth'을 URL로 사용하고, 이 URL에 URL 인코딩을 적용한 값을 사용했다.

  • 4. 키 생성

    • 3번 과정까지 거쳐 생성한 문자열을 암호화한다. 암호화할 때 Consumer Secret Key를 사용한다. Consumer Secret Key는 Consumer가 Service Provider에 사용 등록을 할 때 발급받은 값이다. HMAC-SHA1 등의 암호화 방법을 이용하여 최종적인 oauth_signature를 생성한다.

  • 사용자 인증 페이지의 호출

    • OAuth에서 사용자 인증 페이지를 호출하는 단계는 '안내데스크에서 김목적씨에게 방문한 손님이 있으니 안내 데스크로와서 확인을 요청하는 것'에 비유할 수 있다. Request Token을 요청하면, Service Provider는 Consumer에 Request Token으로 사용할 oauth_token과 oauth_token_secret을 전달한다. Access Token을 요청할 때는 Request Token의 요청에 대한 응답 값으로 받은 oauth_token_secret을 사용한다. Consumer가 웹 애플리케이션이라면 HTTP 세션이나 쿠키 또는 DBMS 등에 oauth_token_secret를 저장해 놓아야 한다.

    oauth_token을 이용해 Service Provider가 정해 놓은 사용자 인증 페이지를 User에게 보여 주도록 한다. 네이버의 경우 OAuth용 사용자 인증 페이지의 주소는 다음과 같다.

    ?
    1
    https://nid.naver.com/naver.oauth?mode=auth_req_token

    여기에 Request Token을 요청해서 반환받은 oauth_token을 매개 변수로 전달하면 된다. 예를 들면 다음과 같은 URL이 만들어 지게 되는 것이다. 이 URL은 사용자 인증 화면을 가리킨다.

    ?
    1
    https://nid.naver.com/naver.oauth?mode=auth_req_token&oauth_token=wpsCb0Mcpf9dDDC2

    로그인 화면을 호출하는 단계까지가 '안내 데스크에서 김목적씨에게 전화하는 단계'라 보면 되겠다. 이제 김목적씨가 안내 데스크로 와서 나방문씨를 확인해야 한다. 정말 나방문씨가 맞는지 아닌지 확인하는 과정이 필요할 것이다. 이 과정이 OAuth에서는 Service Provider에서 User를 인증하는 과정이라고 볼 수 있다.

    인증이 완료되면 앞에서 말한 바와 같이 어떤 권한을 요청하는 단계에 이르게 된다. "업무 약속이 있어 오셨으니 나방문씨가 출입할 수 있게 해 주세요"와 같은 것 말이다.

    인증을 마치면 Consumer가 oauth_callback에 지정한 URL로 리다이렉트한다. 이때 Service Provider는 새로운 oauth_token과 oauth_verifier를 Consumer에 전달한다. 이 값들은 Access Token을 요청할 때 사용한다.

  • Access Token 요청하기

    • OAuth에서의 AccessToken은 나방문 씨에게 지급할 방문증과 같다.

    Access Token을 요청하는 방법은 Request Token을 요청하는 방법과 거의 같다. 다만, 사용하는 매개변수의 종류가 약간 다르고 oauth_signature를 생성할 때 사용하는 키가 다르다. Access Token 을 요청할 때에는 매개변수 oauth_callback는 없고, oauth_token와 oauth_verifer가 있다.

    Request Token 발급을 요청할 때에는 Consumer Secret Key를 사용해 oauth_token_secret를 생성했다. Access Token 발급을 요청할 때에는 Consumer Secret Key에 oauth_token_secret을 결합한 값(Consumer Secret Key + & + oauth_token_secret)을 사용해 oauth_token_secret를 생성한다. 암호화 키를 변경하여 보안을 더 강화하는 것이다.

    Access Token 발급을 요청할 때 사용하는 매개변수는 다음 표와 같다.

    표 5 Access Token 발급 요청을 위한 OAuth 매개변수

    매개변수

    설명

    oauth_consumer_key

    Consumer를 구별하는 키 값. Service Provider는 이 키 값으로 Consumer를 구분한다.

    oauth_nonce

    Consumer에서 임시로 생성한 임의의 문자열. oauth_timestamp의 값이 같은 요청에서는 유일한 값이어야 한다. 이는 악의적인 목적으로 계속 요청을 보내는 것을 막기 위해서이다.

    oauth_signature

    OAuth 인증 정보를 암호화하고 인코딩하여 서명 값. OAuth 인증 정보는 매개변수 중에서 oauth_signature를 제외한 나머지 매개변수와 HTTP 요청 방식을 문자열로 조합한 값이다. 암화 방식은 oauth_signature_method에 정의된다.

    oauth_signature_method

    oauth_signature를 암호화하는 방법. HMAC-SHA1, HMAC-MD5 등을 사용할 수 있다.

    oauth_timestamp

    요청을 생성한 시점의 타임스탬프. 1970년1월 1일 00시 00분 00초 이후의 시간을 초로 환산한 초 단위의 누적 시간이다.

    oauth_version

    OAuth 사용 버전

    oauth_verifier

    Request Token 요청 시 oauth_callback으로 전달받은 oauth_verifier 값

    oauth_token

    Request Token 요청 시 oauth_callback으로 전달받은 oauth_token 값

    위의 표에 정의한 매개변수를 상황에 맞게 정의한 다음 Access Token을 요청하면 oauth_token과 oauth_token_secret을 전달받게 된다. Service Provider에 따라 사용자의 아이디나 프로필 정보 같은 것들이 반환되기도 한다.

  • Access Token 사용하기

    • 드디어 방문증이 발급됐다. 이제 출입문을 통과하는 일만 남았다. 방문증을 가지고 출입문을 통과한다는 것은 User의 권한으로 Service Provider의 기능을 사용하는 것과 비슷하다. 다시 말해, 권한이 필요한 오픈 API를 호출할 수 있게 되는 것이다.

    가령 네이버 카페에서 게시판 목록을 가져온다고 한다면 호출해야 하는 URL은 다음과 같다.

    ?
    1
    http://openapi.naver.com/cafe/getMenuList.xml

    특정 User의 권한을 가지고 카페 게시판 목록 반환 URL을 요청해야 해당 User가 가입한 카페의 게시판 목록을 반환받을 수 있을 것이다. 이 URL을 호출할 때는 OAuth 매개변수를 함께 전달해야 한다.

    다음은 Access Token을 사용해 오픈 API를 요청하는 예이다. HTTP 헤더에 Authorization 필드를 두었고, Authorization 필드의 값 부분에 OAuth 매개변수 적는다. Access Token을 사용할 때는 GET이나 POST가 아닌 HEAD 방식을 사용한다.

    ?
    1
    2
    3
    4
    5
    6
    POST /cafe/getMenuList.xml HTTP/1.1
    Authorization: OAuth oauth_consumer_key="dpf43f3p2l4k3l03",oauth_token="nSDFh734d00sl2jdk"
    ,oauth_signature_method="HMACSHA1",oauth_timestamp="1379123202",oauth_nonce="chapoH",oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
    Accept-Encoding: gzip, deflate
    Connection: Keep-Alive
    Host: http://openapi.naver.com

    보기 쉽도록 Authorization 필드를 아래와 같이 매개변수를 기준으로 정리했다.

    ?
    1
    2
    3
    4
    5
    6
    Authorization: OAuth oauth_consumer_key="dpf43f3p2l4k3l03",
    oauth_token="nSDFh734d00sl2jdk",
    oauth_signature_method="HMACSHA1",
    oauth_timestamp="1379123202",
    oauth_nonce="csrrkjsd0OUhja",
    oauth_signature="MdpQcU8iPGGhytrSoN%2FUDMsK2sui9I%3D"

    Access Token을 사용해 오픈 API를 호출할 때 사용하는 매개변수는 다음 표와 같다.

    표 6 Access Token을 사용해 오픈 API를 호출 할 때 필요한 OAuth 매개변수

    매개변수

    설명

    oauth_consumer_key

    Consumer를 구별하는 키 값. Service Provider는 이 키 값으로 Consumer를 구분한다.

    oauth_nonce

    Consumer에서 임시로 생성한 임의의 문자열. oauth_timestamp의 값이 같은 요청에서는 유일한 값이어야 한다. 이는 악의적인 목적으로 계속 요청을 보내는 것을 막기 위해서이다.

    oauth_signature

    OAuth 인증 정보를 암호화하고 인코딩하여 서명 값. OAuth 인증 정보는 매개변수 중에서 oauth_signature를 제외한 나머지 매개변수와 HTTP 요청 방식을 문자열로 조합한 값이다. 암화 방식은 oauth_signature_method에 정의된다.

    oauth_signature_method

    oauth_signature를 암호화하는 방법. HMAC-SHA1, HMAC-MD5 등을 사용할 수 있다.

    oauth_timestamp

    요청을 생성한 시점의 타임스탬프. 1970년1월 1일 00시 00분 00초 이후의 시간을 초로 환산한 초 단위의 누적 시간이다.

    oauth_version

    OAuth 버전

    oauth_token

    oauth_callback으로 전달받은 oauth_token

     

    주의

    Access Token을 이용해 요청할 때, Service Provider에 따라 realm이라는 매개변수를 사용해야 하는 경우도 있다. realm은 optional 매개변수인데, WWW-Authenticate HTTP 헤더 필드에서 사용하는 값이다.

  • OAuth 2.0

    • OAuth 1.0은 웹 애플리케이션이 아닌 애플리케이션에서는 사용하기 곤란하다는 단점이 있다. 또한 절차가 복잡하여 OAuth 구현 라이브러리를 제작하기 어렵고, 이런저런 복잡한 절차 때문에 Service Provider에게도 연산 부담이 발생한다.

    OAuth 2.0은 이러한 단점을 개선한 것이다. OAuth 1.0과 호환성이 없고, 아직 최종안이 발표된 것은 아니지만 여러 인터넷 서비스 기업에서 OAuth 2.0을 사용하고 있다.

    OAuth 2.0의 특징은 다음과 같다.

    • 웹 애플리케이션이 아닌 애플리케이션 지원 강화
    • 암호화가 필요 없음
      HTTPS를 사용하고 HMAC을 사용하지 않는다.
    • Siganature 단순화
      정렬과 URL 인코딩이 필요 없다.
    • Access Token 갱신
      OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할 수 있었다. 트위터의 경우에는 Access Token을 만료시키지 않는다. OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 했다.

    이외에도 OAuth 2.0에서 사용하는 용어 체계는 OAuth 1.0과 완전히 다르다. 같은 목적의 다른 프로토콜이라고 이해는 것이 좋다. 하지만 아직 최종안이 나오지 않았기 때문에, 현재로서는 OAuth 2.0의 특징만 파악하는 것으로도 충분할 듯 하다.

  • OAuth로 인한 인터넷 서비스의 변화

    • OAuth는 요즘의 인터넷 생태계의 주요 요소로 자리매김하고 있다.

    신생 업체들은 고유의 인증 방식을 사용하기 보다는 Facebook이나 트위터의 인증을 이용하고 있다. 개발 비용과 운영 비용을 줄이는 효과도 있지만 Facebook이나 트위터를 통해 서비스를 홍보하는 효과를 만들 수도 있다. 그리고 Service Provider 입장에서는 핵심 기능을 더욱 공고히 하는 효과를 얻고 있다.

    표준 인증 방법 하나가 인터넷 업계에 변화를 주고 있는 것이다.

    오창훈.jpg
    NHN 소셜앱스서비스팀 오창훈
    2000년부터 웹마스터로 개발을 시작하게 되었고, 아직까지 치킨 장사 안하고 살아남아 자랑스럽게 개발을 하고 있습니다. 앞으로도 그러하겠지요.. 그래서 즐겁고 행복합니다. 전 개발과 관련된 것이면 무엇이든 알고 싶고, Hello World 한번 정도는 꼭 찍어보는 성격입니다. 그냥 만드는 것이 좋습니다. DIY, 프라모델, 캠핑을 취미로 삼고 있습니다. 예전엔 테크니컬리더로 프론트의 신기술 도입이나 적용 그리고 서비스의 최적화 작업을 주로 했었으며, 지금은 NHN에서 오픈소셜 플랫폼의 에반젤리스트 역할을 하고 있습니다.


    출처 - http://helloworld.naver.com/helloworld/24942





    OAuth

    Daum OAuth 소개

    Daum은 Open API를 활용한 개발 도중 부분적으로 필요했던 "인증"의 불편함을 해소하고자 OAuth 프로토콜을 지원합니다. OAuth 인증을 이용하여 개발자는 좀 더 다양한 데이터를 활용한 위젯, 웹사이트, 어플리케이션을 제작할 수 있고, 인증 표준의 부재로 인해 발생했던 불편함을 해소할 수 있게 되었습니다.

    Request 토큰 URL

    https://apis.daum.net/oauth/requestToken

    request 토큰 요청시 oauth_callback 값이 컨슈머의 Callback 경로와 동일해야 합니다.

    사용자 인증 URL

    https://apis.daum.net/oauth/authorize

    Access 토큰 URL

    https://apis.daum.net/oauth/accessToken

    서명 메소드는 HMAC-SHA1만 지원됩니다.

    라이센스

    이 스펙은 OAuth Core 1.0 스펙으로부터 OAuth Non-Assertion Covenant and Author's Contribution license For OAuth Specification 1.0(http://oauth.net/license/core/1.0)에 맞게 파생되었다. OAuth Core 1.0과 OAuth Core 1.0 Revision A 사이의 변경사항은 구글과 야후의 오픈 웹 재단 계약 0.9에 의해 인가되었습니다.

    OAuth Core 1.0에서의 변경사항

    OAuth Core 1.0 Revision A는 http://oauth.net/advisories/2009-1/에 나온 OAuth Core 1.0 스펙의 세션 고정 공격을 해결하기 위해 만들어졌습니다. 변경사항에 대한 전체 내용은 스펙 저장소에서 확인 할 수 있습니다.

    OAuth란?

    • OAuth 프로토콜은 웹사이트나 프로그램(컨슈머)에서 API를 통해서 컨슈머에 대한 사용자 확인 없이 웹서비스(서비스 프로바이더)의 보호된 리소스에 접근할 수 있게 해줍니다. 더 일반적으로, OAuth는 자유로운 구현과 일반적인 API 인증법을 만들수 있게 해줍니다.
    • 예를 들면, printer.example.com(컨슈머) 출력 서비스에서 photos.example.net(서비스 프로바이더)의 사용자 인증 요청없이 개인적인 사진을 출력할 수 있게 해줍니다.
    • OAuth는 사용자 인터페이스나 상호작용과 서비스 프로바이더에서 사용자 인증하는 방벙에 대한 명세가 OpenID처럼 필요없습니다.
    • OAuth 의 목표는 커뮤니티 중심 프로토콜과 웹서비스의 통합인증을 구현하는 것입니다. OAuth는 존재하는 프로토콜과 독립적으로 구현된 여러 웹 사이트 중에서 모범사례를 바탕으로 구현되었고, 개방형 표준과 크고 작은 업체들이 모두 지원하는 개발자와 사용자에게 일관되고 신뢰할 수 있는 경험을 장려합니다.

    용어 정의

    설명에 들어가기 앞서 일단 사용하는 용어에 대해 알아봅시다.

    서비스 프로바이더(Service Provier)
    OAuth를 통해서 접근을 허용하는 웹 애플리케이션.
    사용자(User)
    서비스 프로바이더에 계정을 가지고 있는 개인.
    컨슈머(Consumer)
    OAuth를 사용해서 사용자를 대신해 서비스 프로바이더에 접근하는 웹사이트나 애플리케이션.
    보호된 리소스(Protected Resource)
    컨슈머가 인증을 통해 접근할 수 있는 서비스 프로바이더의 데이터.
    컨슈머 개발자(Consumer Devloper)
    컨슈머를 규현하는 개인이나 단체.
    컨슈머 키(Consumer Key)
    컨슈머가 서비스 프로바이더에 자신을 나타내는 값. 
     => 컨슈머 개발자가 서비스 프로바이더에서 발급
    컨슈머 시크릿(Consumer Secret)
    컨슈머가 컨슈머 키의 소유권을 입증하는데 사용하는 시크릿. 
     => 컨슈머 개발자가 서비스 프로바이더에서 발급
    Request 토큰
    컨슈머가 사용자에게 인증을 획득하기 위해 사용하는 값. 접근 토큰으로 교체됨. 
     => 컨슈머가 서비스 프로바이더에 요청
    Access 토큰
    컨슈머가 서비스 프로바이더의 사용자 인증을 사용한 사용자 대신 보호된 리소스에 접근 권한을 얻는데 사용되는 값. 
     => 컨슈머가 서비스 프로바이더에 요청
    토큰 시크릿(Token Secret)
    컨슈머가 토큰의 소유권을 입증하는데 사용하는 시크릿. 
     => 컨슈머가 서비스 프로바이더에 요청
    OAuth 프로토콜 파라미터(OAuth Protocol Parameter)
    이름이 "oauth_"로 시작하는 파라미터.

    컨슈머 등록

    컨슈머 개발자는 서비스 프로바이더의 데이터를 사용하는 어플리케이션이나 웹사이트를 제작하기 위해 서비스 프로바이더의 OAuth 어플리케이션 등록 페이지에서 어플리케이션을 등록하고, 컨슈머 키와 컨슈머 시크릿을 발급받아야 합니다.

    1. 요청 URL (서비스 프로바이더에서 준비)

    • OAuth는 기본적으로 다음의 3개의 URL이 필요합니다. 이 URL들은 컨슈머가 따로 저장하고 있다가 필요시마다 호출합니다.
      • Request 토큰 URL(Request Token URL) : Request 토큰을 요청하는 URL
      • 사용자 인증 URL(Authorization URL) : 컨슈머가 사용자의 보호된 리소스에 대한 접근을 허용할지 결정하는 URL
      • Access 토큰 URL(Access Token URL) : 사용자가 인증한 Request 토큰을 Access 토큰으로 교환하는 URL

    2. 서비스 프로바이더

    • 서비스 프로바이더는 컨슈머 개발자에게 컨슈머 키와 컨슈머 시크릿을 발급하고, 사용할 수 있게 해야합니다
    • 서비스 프로바이더는 다음 문서들을 제공합니다.
      • 컨슈머가 OAuth 요청을 만들때 사용하는 URL과 리퀘스트 토큰 URL이나 액세스 토큰 URL에 사용하는 HTTP 메소드(예 : GET, POST)
      • 서비스 프로바이더에서 제공하는 서명 메소드
      • 서비스 프로바이더에서 토큰을 획득하는데 필요한 추가적인 요청 파라미터. 이 파라미터들은 'oauth_'로 시작하면 안됩니다.

    3. 컨슈머

    • 컨슈머 개발자는 서비스 프로바이더에서 컨슈머 키와 컨슈머 시크릿을 발급받습니다.
    • 컨슈머 개발자는 컨슈머를 등록할 때 서비스 프로바이더에 추가적인 정보를 제공해야할 수 있습니다.

    파라미터

    OAuth 프로토콜 파라미터의 이름과 값은 대소문자를 구별합니다. 각 파라미터들은 요청당 한 번 초과로 나올수 없고, 공지되지 않는 한은 계속 필요합니다.

    1. 파라미터 인코딩

    • 모든 파라미터의 이름과 값은 {RFC3986}의 퍼센트 인코딩(%xx) 매커니즘으로 이스케이프됩니다. 예약되지 않은 문자{RFC3986}에 포함되지 않는 문자들은 인코딩해야합니다. 예약되지 않은 문자들은 인코딩하면 안됩니다. 인코딩된 16진수의 문자는 반드시 대문자여야 합니다. 텍스트의 이름과 문자는 8진수 퍼센트 인키동하기전에 UTF8로 인코딩합니다{RFC3629}.

      unreserved = ALPHA, DIGIT, '-', '.', '_', '~'

    2. 컨슈머 요청 파라미터

    • OAuth 프로토콜 파라미터는 컨슈머에서 서비스 프로바이더에 다음의 세 가지 중 하나의 방법으로 보냅니다. (선호되는 순서대로 나열)
      1. OAuth HTTP 인증 스키마의 HTTP 인증 헤더
      2. content-type이 application/x-www-form-urlencoded인 HTTP POST 요청
      3. 쿼리 파라미터로 URL에 추가 {RFC3986}
    • 이후의 확장에는 위에 정의된 방법 외에도 OAuth Protocol Parameters를 보내는 다른 방법들이 추가될 수도 있습니다. 추가적인 요청 파라미터를 보내는 방법은 아직 정의되지 않았지만 OAuth HTTP 인증 스키마 헤더는 사용하지 않는 것이 좋습니다.

    3. 서비스 프로바이더 응답 파라미터

    • 서비스 프로바이더에서 토큰과 기타 정보들을 HTTP response body에 담아 응답 파라미터를 컨슈머에 보냅니다. 파라미터 이름과 값은 {파라미터 인코딩}한 후 '&'(ASCII 코드 8)로 이어져 있습니다. 예시

      oauth_token=ab3cd9j4ks73hf7g&oauth_token_secret=xyz4992k83j47x0b

    4. OAuth HTTP 인증 스키마

    • OAuth 프로토콜 파라미터를 전달하는데 표준 HTTP 인증과 WWW-인증을 사용합니다.
    • 서비스 프로바이더는 HTTP 인증 헤더를 수락하는게 추천됩니다. 컨슈머는 OAuth 프로토콜 파라미터를 OAuth 인증 헤더를 통해 보낼 수 있어야 합니다.
    • 확장된 인증 스키마({RFC2617})는 대소문자 구별없는 OAuth입니다.

    1. 인증 헤더

    • OAuth 프로토콜 파라미터는 다음과 같은 방법으로 인증 헤더를 보냅니다.
      1. 파라미터의 이름과 값을 {파라미터 인코딩}으로 인코딩합니다.
      2. 각 파라미터는 이름뒤에 '='(ASCII 코드 61)가 오고 파라미터의 값은 '"'(ASCII 코드 34)로 쌓여있습니다.
      3. 각 파라미터들은 쉼표(ASCII 코드 44)와 줄바꿈(옵션)으로 나누어집니다.
      4. 옵션인 realm 파라미터가 추가되고 해석됩니다.
    • 예시

      Authorization: OAuth realm="http://sp.example.com/",
      oauth_consumer_key="0685bd9184jfhq22",
      oauth_token="ad180jjd733klru7",
      oauth_signature_method="HMAC-SHA1",
      oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",
      oauth_timestamp="137131200",
      oauth_nonce="4572616e48616d6d65724c61686176",
      oauth_version="1.0"

    2. WWW-인증 헤더

    • 서비스 프로바이더는 컨슈머의 보호된 리소스 요청에 의해 리턴되는 OAuth HTTP WWW-인증 헤더의 확장을 지원하기 위해 추가적인 HTTP WWW-인증 헤더를 응답에 포함할 수 있습니다.
    • 예시

      WWW-Authenticate: OAuth realm="http://sp.example.com/"

    • ealm 파라미터는 {RFC2617}으로 제한된 realm을 정의합니다.

    OAuth로 인증하기

    OAuth 인증은 사용자가 보호된 리소스에 대한 접근을 컨슈머에게 허용하는 과정입니다. OAuth는 보호된 리소스에 접근하는데 사용자 인증을 대신해 서비스 프로바이더에서 생성한 토큰을 사용합니다. 이 과정은 다음 두 토큰을 사용합니다.

    • Request 토큰 : 컨슈머가 보호된 리소스에 대한 접근 허용을 사용자에게 요청하는데 사용됩니다. 사용자가 인증한 Request 토큰은 한 번만 사용되고, Access 토큰으로 교체됩니다. Request 토큰은 제한된 수명이 있는 것이 권장됩니다.
    • Access 토큰 : 컨슈머가 보호된 리소스에 사용자 대신 접근하는데 사용됩니다. Access 토큰은 보호된 리소스에 제한적으로 접근할 수 있고, 제한된 수명을 가지고 있을 것입니다. 서비스 프로바이더는 사용자에게 Access 토큰을 파기할 수 있도록 해야합니다. 보호된 리소스에 접근이 허용된 Access 토큰만 사용할 수 있습니다.

    OAuth 인증은 다음 세단계로 이루어집니다.

    1. 컨슈머가 인증되지 않은 Request 토큰 요청
    2. 사용자가 Request 토큰 인증
    3. 컨슈머는 Request 토큰을 Access 토큰으로 교환

    1. 인증되지 않은 Request 토큰 획득

    컨슈머는 서비스 프로바이더에 토큰 발급을 요청해서 인증되지 않은 Request 토큰을 획득합니다. request 토큰의 유일한 목적은 Access 토큰을 획득하기위해 사용자의 승인을 받는 것입니다. Request 토큰 요청 프로세스는 다음과 같습니다.

    1) 컨슈머가 Request 토큰 획득

    Request 토큰을 획득하기 위해 컨슈머는 서비스 프로바이더의 Request 토큰 URL에 HTTP 요청을 보내야합니다. 서비스 프로바이더의 문서에는 이 요청에 대한 HTTP 메소드(HTTP POST 권장)를 명세합니다. 요청은 다음의 파라미터를 포함해야 합니다.

    oauth_consumer_key
    컨슈머 키
    oauth_signature_method
    컨슈머가 서명에 사용하는 서명 메소드
    oauth_signature
    {요청 서명}에 정의된 signature
    oauth_timestamp
    타임스탬프. January 1, 1970 00:00:00 GMT 부터 시작된 초단위 숫자. 양수여야되고, 이전 요청의 타임스탬프보다 커야합니다.
    oauth_nonce
    컨슈머에서 생성한 임의적인 문자열. 같은 타임스탬프 내에서는 유일한 값이어야 합니다. nonce는 서비스 프로바이더가 HTTP 같은 비보안 채널에서 요청을 계속 만들어내는 공격을 알아낼 수 있게합니다.
    oauth_callback
    서비스 프로바이더가 {사용자 인증 획득하기}과정 완료 후 리다이렉트시킬 절대 URL. 컨슈머가 콜백을 받지 못하거나 콜백 URL로 이동을 할 수 없는 상태이면(예 : 어플리케이션) 값은 out-of-band를 뜻하는 oob(대소문자 구별)로 셋팅 되어야 합니다.
    추가적인 파라미터
    서비스 프로바이더에 의해 정의된 추가적인 파라미터

    2) 서비스 프로바이더의 인증되지 않은 Request 토큰 발급

    • 서비스 프로바이더는 signature와 컨슈머 키를 검증합니다. 검증이되면 컨슈머에게 Request 토큰과 토큰 시크릿을 HTTP response body에 담아({서비스 프로바이더 응답 파라미터}) 리턴합니다. 서비스 프로바이더는 {사용자 인증을 획득하기}전에는 Request 토큰을 Access 토큰으로 교환해주면 안됩니다.
    • 응답 파라미터들은 다음과 같습니다.
      oauth_token
      Request 토큰
      oauth_token_secret
      토큰 시크릿
      oauth_callback_confirmed
      true로 설정되있어야 합니다. 컨슈머는 이것을 서비스 프로바이더가 콜백 값을 받는 것을 승인하는데 사용할 수 있습니다.
      추가적인 파라미터
      서비스 프로바이더에 의해 정의된 추가적인 파라미터
    • 검증을 실패하거나 기타 이유때문에 거절되면 서비스 프로바이더는 적절한 {HTTP 응답 코드}로 응답을 해야 합니다. 서비스 프로바이더는 응답이 외 거절되었는지 이유를 HTTP response body에 담아 {서비스 프로바이더 응답 파라미터}로 나타낼 수 있습니다.

    2. 사용자 인증 획득

    컨슈머는 사용자가 인증하기 전까지는 Request 토큰을 사용할 수 없습니다. 사용자 인증을 획득하는 과정은 다음과 같습니다.

    1) 컨슈머가 사용자를 서비스 프로바이더에게 보내기

    • 컨슈머가 Request 토큰을 Access 토큰으로 교환하려면 컨슈머는 사용자를 서비스 프로바이더에 보내 승인을 받아야합니다. 컨슈머는 서비스 프로바이더의 사용자 인증 URL을 다음 파라미터를 붙여서 HTTP GET 요청을 구성할 수 있습니다.
      oauth_token
      (옵션) 이전 과정에서 획득한 Request 토큰. 서비스 프로바이더는 이 파라미터를 필수 파라미터로 지정할 수도 있고, 이 파라미터 없이 사용자 인증 URL에서 사용자가 직접 입력하게 받아들일 수도 있습니다.
      추가적인 파라미터
      서비스 프로바이더에 의해 정의된 추가적인 파라미터
    • 요청 URL이 완성되면 컨슈머난 사용자의 웹 브라우저를 URL로 이동시킵니다. 컨슈머가 자동으로 이동시킬 수 없으면 사용자에게 요청 URL로 가는 방법을 알려줍니다.
    • 참고 : 서비스 프로바이더가 컨슈머가 모바일 장치나 셋톱박스에서 구동되는 것을 알고 있으면 서비스 프로바이더는 사용자 인증 URL과 Request 토큰은 수동입력에 적합해야합니다.

    2) 서비스 프로바이더가 사용자를 인증하고 동의를 구함

    • 서비스 프로바이더가 사용자 신원을 확인하고, 세부사항에 대해 동의를 구합니다. OAuth는 서비스 프로바이더가 사용자 인증을 하는 방법에 대해 지정하지 않습니다. 그렇지만, 다음과 같은 단계는 거쳐야 합니다.
      • 서비스 프로바이더는 동의를 구하기 전에 사용자의 신원을 확인해야 합니다. 사용자가 로그인을 하지 않았으면 로그인 화면을 보여줄 것입니다.
      • 서비스 프로바이더는 (컨슈머 개발자가 등록한)컨슈머가 접근요청을 하는 사용자의 정보에 대해 표시합니다. 이 정보는 지속적으로 접근할 보호된 리소스도 포함합니다. 나머지 자세한 내용은 서비스 프로바이더에 포함할 수 있습니다.
      • 사용자는 사용자대신 컨슈머가 보호된 리소스에 접근하게하는 권한을 허용하거나 거부해야 합니다. 사용자가 컨슈머의 접근을 거부하면 서비스 프로바이더는 보호된 리소스에 대한 접근을 허용하지 않습니다.
    • 컨슈머 키를 사용해서 온 사용자에게 컨슈머에 대한 식별정보를 보여줄 때 서비스 프로바이더는 컨슈머가 정확히 식별되지 않으면 이를 사용자에게 알려야 합니다. 서비스 프로바이더가 사용자에게 알리는 방법이나 식별방법은 이 스펙에 명세되어있지 않습니다.

    3) 서비스 프로바이더가 사용자를 컨슈머에게 다시 보냄

    • 서비스 프로바이더에서 컨슈머의 접근을 허용하는 사용자 인증 후 컨슈머는 Reqest 토큰은 인증되었고, Access 토큰으로 교환할 준비를 한다는 내용을 알리고, 사용자가 접근을 거부했으면 컨슈머는 Request 토큰이 파기되었다는 것을 알려야 합니다.
    • 접근을 허용한 사용자가 과정을 완료하기 위해 컨슈머에게 보낸 사용자가 같은지 검증하기 위해 서비스 프로바이더는 사용자를 통해서 프로바이더에 전달할 검증 코드를 생성합니다.
    • 컨슈머가 콜백 URL(oauth_callback)을 제공한다면 서비스 프로바이더는 이것을 HTTP 요청을 다음의 파라미터를 추가해 구성하고 사용자의 웹 브라우저를 이동하는데 사용합니다.
      oauth_token
      사용자인증이 되거나 거부된 Request 토큰
      oauth_verifier
      검증 코드
    • 콜백 URL은 컨슈머의 쿼리 파라미터를 포함합니다. 서비스 프로바이더는 이 파라미터들을 그대로 유지하고, OAuth 파라미터를 추가합니다.
    • 컨슈머가 콜백 URL을 제공하지 않으면 서비스 프로바이더는 검증코드를 보여주고, 사용자에게 이 코드를 컨슈머에 직접 입력하게 합니다. 서비스 프로바이더가 컨슈머가 모바일 장치나 셋톱박스에서 구동되는 것을 알고 있으면 서비스 프로바이더는 사용자 인증 URL과 Request 토큰은 수동입력에 적합해야합니다.

    3. Access 토큰 획득

    컨슈머는 Request 토큰을 보호된 리소스에 접근할 수 있는 Access 토큰으로 교환합니다. Access 토큰을 획득하는 과정은 다음과 같습니다.

    1) 컨슈머의 Access 토큰 요청

    • Request 토큰과 토큰 시크릿은 Access 토큰과 토큰 시크릿으로 교환됩니다.
    • Access 토큰을 요청하기 위해 컨슈머는 서비스 프로바이더의 Access 토큰 URL에 HTTP 요청을 합니다. 서비스 프로바이더에서는 이 요청에 대한 HTTP 메소드(HTTP POST 권장)에 대해 명세를 해야합니다. 이 요청은 {요청 서명}으로 서명하고, 다음의 파라미터를 포함해야 합니다.
      oauth_consumer_key
      컨슈머 키
      oauth_token
      이전단계에 획득한 Request 토큰
      oauth_signature_method
      컨슈머가 서명에 사용하는 서명 메소드
      oauth_signature
      {요청 서명}에 정의된 signature
      oauth_timestamp
      타임스탬프. January 1, 1970 00:00:00 GMT 부터 시작된 초단위 숫자. 양수여야되고, 이전 요청의 타임스탬프보다 커야합니다.
      oauth_nonce
      컨슈머에서 생성한 임의적인 문자열. 같은 타임스탬프 내에서는 유일한 값이어야 합니다. nonce는 서비스 프로바이더가 HTTP 같은 비보안 채널에서 요청을 계속 만들어내는 공격을 알아낼 수 있게합니다.
      oauth_version
      (옵션) 이 문서를 기준으로는 1.0이어야 합니다. 이 파라미터를 생략하면 서비스 프로바이더는 1.0이라고 간주하고, 1.0이 아닌 값에 대한 서비스 프로바이더의 응답은 정의되지 않았습니다.
      oauth_verifier
      이전단계에 서비스 프로바이더에서 받은 검증 코드
    • Access 토큰을 요청하는 단계에는 토큰에 관련된 정보를 확실히 하기 위해 서비스 프로바이더에서 지정한 추가적인 파라미터는 허용되지 않습니다.

    2) 서비스 프로바이더의 Access 토큰 허용

    • 서비스 프로바이더는 다음을 보증해야합니다.
      • - 요청 서명은 확실히 검증해야합니다.
      • - Request 토큰은 Access 토큰으로 교체된 적이 없어야 합니다.
      • - Request 토큰은 컨슈머 키와 일치해야 합니다.
      • - 컨슈머에서 받은 검증 코드는 검증되어야 합니다.
    • 서비스 프로바이더에서 Access 토큰과 토큰 시크릿이 생성되면 {서비스 프로바이더 응답 파라미터}를 HTTP response body에 담아 리턴합니다. Access 토큰과 토큰 시크릿은 컨슈머에 저장되고, 보호된 리소스를 요청하는데 사용합니다. 응답은 다음의 파라미터를 포함합니다.
      oauth_token
      Access 토큰
      oauth_token_secret
      토큰 시크릿
      추가적인 파라미터
      서비스 프로바이더에 의해 정의된 추가적인 파라미터
    • 검증을 실패하거나 기타 이유때문에 거절되면 서비스 프로바이더는 적절한 {HTTP 응답 코드}로 응답을 해야 합니다. 서비스 프로바이더는 응답이 외 거절되었는지 이유를 HTTP response body에 담아 {서비스 프로바이더 응답 파라미터}로 나타낼 수 있습니다.

    보호된 리소스에 접근

    Access 토큰과 토큰 시크릿을 받은 후 컨슈머는 사용자 대신 보호된 리소스에 접근할 수 있습니다. 요청은 {요청 서명}으로 서명되야하고, 다음의 파라미터를 포함합니다.

    oauth_consumer_key
    컨슈머 키
    oauth_token
    Access 토큰
    oauth_signature_method
    컨슈머가 서명에 사용하는 서명 메소드
    oauth_signature
    {요청 서명}에 정의된 signature
    oauth_timestamp
    타임스탬프. January 1, 1970 00:00:00 GMT 부터 시작된 초단위 숫자. 양수여야되고, 이전 요청의 타임스탬프보다 커야합니다.
    oauth_nonce
    컨슈머에서 생성한 임의적인 문자열. 같은 타임스탬프 내에서는 유일한 값이어야 합니다. nonce는 서비스 프로바이더가 HTTP 같은 비보안 채널에서 요청을 계속 만들어내는 공격을 알아낼 수 있게합니다.
    oauth_version
    (옵션) 이 문서를 기준으로는 1.0이어야 합니다. 이 파라미터를 생략하면 서비스 프로바이더는 1.0이라고 간주하고, 1.0이 아닌 값에 대한 서비스 프로바이더의 응답은 정의되지 않았습니다.
    추가적인 파라미터
    서비스 프로바이더에 의해 정의된 추가적인 파라미터

    Nonce와 타임스탬프

    • 타임스탬프는 January 1, 1970 00:00:00 GMT 부터 시작된 초단위 숫자입니다. 양수여야되고, 이전 요청의 타임스탬프보다 커야합니다.
    • Nonce는 컨슈머에서 생성한 임의적인 문자열입니다. 같은 타임스탬프 내에서는 유일한 값이어야 합니다. nonce는 서비스 프로바이더가 HTTP 같은 비보안 채널에서 요청을 계속 만들어내는 공격을 알아낼 수 있게합니다.

    요청 서명

    • 모든 토큰 요청과 보호된 리소스 요청은 반드시 컨슈머에 의해 서명되고, 서비스 프로바이더에 의해 검증 되야합니다. 요청 서명의 목적은 토큰이나 보호된 리소스를 요청할 때 인증되지 않은 서명자의 컨슈머 키와 토큰 사용을 방지하는 것입니다. 사인 과정은 컨슈머 시크릿을 인코딩하고, 토큰 시크릿을 요청에 포함함된 검증 가능한 값으로 넣는 것입니다.
    • OAuth는 특정 서명 메소드를 지정하지 않습니다. 각각 구현의 고유한 요구사항을 가질 수 있습니다. 프로토콜은 HMAC-SHA1, RSA-SHA1, PLAINTEXT 세 가지의 서명 메소드를 정의하지만 서비스 프로바이더는 새로 구현해서 사용할 수 있고, 특정 메소드를 추천하지는 않습니다.
    • 컨슈머는 서명 메소드를 oauth_signature_method 파라미터에 선언하고, 생성한 Signature를 oauth_signature 파라미터에 저장합니다. 서비스 프로바이더는 지정된 메소드로 Signature를 검증합니다. 컨슈머의 Signature를 검증할 때 서비스 프로바이더는 요청 nonce가 이전 컨슈머 요청에 사용되지 않았는지 확인해야 합니다.
    • 서명 과정은 요청 oauth_signature 파라미터를 제외하고 파라미터의 이름과 값을 절대 바꾸지 않습니다.

    1. Signature 기본 문자열

    Signature 기본 문자열은 일관적으로 재생가능한 단일 문자열 요청요소의 연결입니다. 문자열은 해싱이나 서명 알고리즘의 입력으로 사용됩니다. HMAC-SHA1 서명 메소드는 표준과 signature를 생성하기 위한 서명 알고리즘과 함께 signature 기본 문자열 예시를 제공합니다. 모든 요청 파라미터는 signature 기본 문자열을 생성하기 전에 {파라미터 인코딩}에 설명된 데로 인코딩되야 합니다.

    1) 요청 파라미터의 표준화

    • 요청 파라미터는 정렬, 결합되서 표준화된 문자열에 수집됩니다.
      • - realm 파라미터를 제외한 {OAuth HTTP 인증 해더}의 파라미터
      • - HTTP POST request body의 파라미터(application/x-www-form-urlencoded의 content-type 포함)
      • - URL의 쿼리 파라미터 부분에 추가된 HTTP GET 파라미터
    • oauth_signature 파라미터는 반드시 제외합니다.
    • 파라미터를 단일 문자열로 표준화하면 다음과 같습니다.
      1. 파라미터는 이름의 오름차순으로 정렬합니다. 같은 이름이 있으면 값에 의해 정렵합니다.

        a=1, c=hi%20there, f=25, f=50, f=a, z=p, z=t

      2. 정렬된 파라미터를 단일 문자열로 연결시킵니다. 각 파라미터는 값과 '='(ASCII 코드 61)로 분리되어있습니다.(비어있는 값도 적용) 각 이름-값 쌍을 '&'(ASCII 코드 38)로 분리합니다.

        a=1&c=hi%20there&f=25&f=50&f=a&z=p&z=t

    2) 요청 URL 생성

    • Signature 기본 문자열은 특정 종단 요청의 절대 URL을 포함합니다. URL은 Signature 기본 문자열에서 스키마, 권한, 경로를 포함시키고, 쿼리와 단편들을 제외시키는데 사용합니다.
    • 절대 요청 URL을 서비스 프로바이더에 사용할 수 없다면(컨슈머에는 항상 가능) HTTP Host header와 관련된 HTTP 요청 URL을 사용하고 있는 스키마와 조합해서 생성할 수 있습니다. Host header를 사용할 수 없다면 서비스 프로바이더는 컨슈머에서 문서나 다른 방법으로 전달된 host 이름을 사용해야 합니다.
    • 서비스 프로바이더는 URL 표준화를 하는 동안 모호함을 피하기 위해 Signature 기본 문자열에 사용하는 URL 형태를 제공해야 합니다. 정리된 것을 제외하고는 URL스키마와 권한은 소문자로 표시하고 포트번호를 포함하는데 http의 기본 포트인 80과 https의 기본 포트인 443은 제외합니다. 다음과 같은 요청은

      HTTP://Example.com:80/resource?id=123

      다음과 같이 Signature 기본 문자열에 포함됩니다.

      http://example.com/resource

    3) 요청 요소 연결

    • 다음 아이템들은 단일 문자열로 반드시 연결되야 합니다. 각 아이템은 {인코딩:파라미터 인코딩}되야 하고, '&'(ASCII 코드 38)로 구분되야 합니다.
      • - HTTP 요청 메소드는 요청을 보내는데 사용됩니다. 값은 반드시 다음과 같이 대문자여야 합니다. : HEAD, GET, POST, 등
      • - {요청 URL 생성}에서 생성된 요청 URL
      • - {요청 파라미터의 표준화}에서 표준화된 요청 파라미터 문자열
    • Signature 기본 문자열에 대한 예재는 {부록 Signature 기본 문자열 생성} 참조

    2. HMAC-SHA1

    HMAC-SHA1 서명 메소드는 RFC2104에 정의된 HMAC-SHA1 서명 알고리즘을 사용합니다. Signature 기본 문자열이 text, 컨슈머 키와 토큰 시크릿을 '&'(ASCII 코드 38) 구분자로 연결한 값이 key가 됩니다.

    1) Signature 생성

    • oauth_signature는 8자리 문자로 계산하여 설정됩니다. 우선 base64로 인코딩되고, {파라미터 인코딩}으로 URL 인코딩합니다.

    2) Signature 검증

    • 서비스 프로바이더는 요청에서 생성된 signature 8자리 문자와 컨슈머에서 넘어온 signature를 비교해서 요청을 검증합니다. 우선 {파라미터 인코딩}으로 디코딩하고, base64로 디코딩합니다. signature는 컨슈머에서 넘어온 요청 파라미터와 서비스 프로바이더에 저장 돼있는 컨슈머 키, 토큰 시크릿을 사용해서 만들어 냅니다.

    3. RSA-SHA1

    RSA-SHA 서명 메소드는 RFC3447에 정의된 RSASSA-PKCS1-v1_5 서명 알고리즘(짧게는 PKCS#1)을 사용합니다. SHA-1은 RSASSA-PKCS1-v1_5에 해시 함수로 사용됩니다. 컨슈머는 서비스 프로바이더가 검증하는데 RSA 공개키를 제공한다고 가정하고, 이것에 대해서는 이 문서에서 정의하지 않습니다.

    1) Signature 생성

    • ignature 기본 문자열은 {RFC3447}에 명시된 컨슈머의 RSA 비공개키를 사용해서 서명합니다. K는 컨슈머의 RSA 비공개키이고, M은 Signature 기본 문자열이고, S는 서명 결과은 8자리 문자열입니다.

      S = RSASSA-PKCS1-V1_5-SIGN (K, M)

    • oauth_signature은 S에 셋팅됩니다. 우선 base64로 인코딩하고 {파라미터 인코딩}으로 URL 인코딩합니다.

    2) Signature 검증

    • 서비스 프로바이더는 {RFC3447}로 서명을 검증합니다. (n e)는 컨슈머의 RSA 공개키이고, M은 Signature 기본 문자열이고 S는 oauth_signature의 값인 8자리 문자열입니다.

      RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S)

    4. PLAINTEXT

    PLAINTEXT 메소드는 보안적인 장치를 제공하지 않고, HTTPS 같은 보안 채널을 사용해야 합니다. Signature 기본 문자열에 사용하지 않습니다.

    1) Signature 생성

    • oauth_signature은 인코딩된 컨슈머 키와 토큰 시크릿을 '&'(ASCII 코드 38) 구분자로 연결합니다. 결과는 다시 인코딩됩니다.
    • 다음 예는 컨슈머 시크릿이 djr9rjt0jd78jf88일 때 서로 다른 3개의 토큰 시크릿에 대한 oauth_signature의 값을 보여줍니다.
      jjd999tj88uiths3
      oauth_signature=djr9rjt0jd78jf88%26jjd999tj88uiths3
      jjd99$tj88uiths3
      oauth_signature=djr9rjt0jd78jf88%26jjd99%2524tj88uiths3
      Empty
      oauth_signature=djr9rjt0jd78jf88%26

    2) Signature 검증

    • 서비스 프로바이더는 signature에서 컨슈머 시크릿과 토큰 시크릿을 분리하여 저장하고 있는 것과 비교해 요청을 검증합니다.

    HTTP 응답 코드

    이 섹션은 Request 토큰과 Access 토큰에만 적용됩니다. 일반적으로, 서비스 프로바이더는 {RFC2616}에 정의된 응답코드를 사용합니다. 서비스 프로바이더가 컨슈머의 요청을 거절했을 때 HTTP 400 Bad Request이나 HTTP 401 Unauthorized를 응답합니다.

    • HTTP 400 Bad Request
      • Unsupported parameter
      • Unsupported signature method
      • Missing required parameter
      • Duplicated OAuth Protocol Parameter
    • HTTP 401 Unauthorized
      • Invalid Consumer Key
      • Invalid / expired Token
      • Invalid signature
      • Invalid / used nonce

    보안 고려사항

    부록 : 프로토콜 예제

    • 서비스 프로바이더가 사진을 공유하는 웹사이트(photos.example.net)이고, 컨슈머는 사진 인화 사이트(printer.example.com)이라고 가정합니다. 사용자 Jane은 printer.example.com(이하 '출력 사이트')에서 photo.example.net(이하 '사진 사이트')에 저장된 비공개 사진 vacation.jpg을 출력하려는 상황을 예로 설명합니다.
    • Jane은 photo.example.net에 로그인해서 사진 URL http://photo.example.net/photo?file=vacation.jpg를 알아냈습니다. 다른 사용자는 이 사진을 볼 수 없고, Jane은 아이디와 패스워드를 printer.example.com에 저장하기 꺼림칙해합니다.
    • 이 예재의 요청은 파라미터를 보낼 때 URL 쿼리 메소드를 사용합니다. 이것은 예재를 간단히 보여주기 위한 것이지 다른 곳에도 보증된 메소드는 아닙니다.

    1. 설명서와 등록

    • 서비스 프로바이더 설명서는 컨슈머 키와 컨슈머 시크릿을 어떻게 등록하는지와 다음 URL에 대한 안내가 있어야 합니다.
      Request 토큰 URL
      https://photos.example.net/request_token / HTTP POST 사용
      사용자 인증 URL
      http://photos.example.net/authorize / HTTP GET 사용
      Access 토큰 URL
      https://photos.example.net/access_token / HTTP POST 사용
      Photo(보호된 리소스) UR
      http://photo.example.net/photo / file 파라미터가 필요하고 옵션으로 size 파라미터가 있음
    • 서비스 프로바이더는 HMAC-SHA1 서명 메소드를 모든 요청에 지원하고, PLAINTEXT는 보안(HTTPS) 요청에만 지원합니다.
    • 컨슈머 출력 사이트는 사진 사이트에 컨슈머 키와 컨슈머 시크릿을 이미 생성하고, 사진 사이트의 사진을 프린트가 되게 작성해 놓은 상태입니다. 컨슈머 등록 코드는 다음과 같습니다.
      컨슈머 키
      dpf43f3p2l4k3l03
      컨슈머 시크릿
      kd94hf93k423kf44

    2. Request 토큰 획득

    • Jane은 출력 사이트에서 사진 사이트에 있는 휴가 사진을 출력을 하려 했지만 출력 사이트에서 사진에 접근하려 하자 비공개 사진이라는 다음 헤더와 함께 HTTP 401 Unauthorized 코드를 응답 받았습니다.

      WWW-Authenticate: OAuth realm="http://photos.example.net/"

    • 컨슈머는 다음 HTTP POST 요청을 서비스 프로바이더에 보냅니다.

      https://photos.example.net/request_token?oauth_consumer_key=dpf43f3p2l4k3l03&oauth_signature_method=PLAINTEXT &oauth_signature=kd94hf93k423kf44%26&oauth_timestamp=1191242090 &oauth_nonce=hsu94j3884jdopsl&oauth_version=1.0&oauth_callback=http%3A%2F%2Fprinter.example.com%2Frequest_token_ready

      https://photos.example.net/request_token?oauth_consumer_key=[컨슈머 키]&oauth_signature_method=[서명 메소드] &oauth_signature=[URL 인코딩한 '컨슈머 시크릿&토큰 시크릿'(토큰 시크릿은 아직 없으니 '컨슈머 시크릿&')]&oauth_timestamp=[타임스탬프] &oauth_nonce=[nonce]&oauth_version=[OAuth 버전]&oauth_callback=[URL 인코딩한 콜백 URL]

    • 서비스 프로바이더는 서명을 확인하고 인증되지 않은 Request 토큰을 HTTP response body에 실어 응답합니다.

      oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&oauth_callback_confirmed=true

      oauth_token=[생성한 Request 토큰]&oauth_token_secret=[생성한 토큰 시크릿]&oauth_callback_confirmed=[콜백 허용]

    3. 사용자 인증 요청

    • 컨슈머는 비공개 사진에 접근하는 승인을 얻기 위해 Jane의 브라우저를 서비스 프로바이더의 사용자 인증 URL로 이동시킵니다.

      http://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola

      http://photos.example.net/authorize?oauth_token=[프로바이더에서 받은 Request 토큰]

    • 서비스 프로바이더는 Jane에게 로그인 한 후 출력 사이트에 비공개 사진에 접근을 허용을 요청합니다. Jane이 요청을 허용하면 서비스 프로바이더는 검증 코드를 생성하고 컨슈머의 콜백 URL로 보냅니다.

      http://printer.example.com/request_token_ready?oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884

      http://printer.example.com/request_token_ready?oauth_token=[Request 토큰]&oauth_verifier=[생성한 검증코드]

    4. Access 토큰 획득

    • 이제 컨슈머는 Jane의 인증된 Request 토큰을 가지고 있으니 이것을 서비스 프로바이더에서 Access 토큰으로 교환해야 합니다.

      https://photos.example.net/access_token?oauth_consumer_key=dpf43f3p2l4k3l03&oauth_token=hh5s93j4hdidpola &oauth_signature_method=PLAINTEXT&oauth_signature=kd94hf93k423kf44%26hdhd0244k9j7ao03&oauth_timestamp=1191242092 &oauth_nonce=dji430splmx33448&oauth_version=1.0&oauth_verifier=hfdp7dh39dks9884

      https://photos.example.net/access_token?oauth_consumer_key=[컨슈머 키]&oauth_token=[Request 토큰] &oauth_signature_method=[서명 메소드]&oauth_signature=[URL 인코딩한 '컨슈머 시크릿&토큰 시크릿']&oauth_timestamp=[타임스탬프] &oauth_nonce=[nonce]&oauth_version=[OAuth 버전]&oauth_verifier=[검증코드]

    • 서비스 프로바이더는 서명과 검증 코드를 확인하고, Access 토큰을 HTTP response body에 실어 응답합니다.

      oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00

      oauth_token=[생성한 Access 토큰]&oauth_token_secret=[새로 생성한 토큰 시크릿]

    5. 보호된 리소스에 접근하기

    컨슈머는 이제 비공개 사진에 접근할 수 있습니다. 사진 URL이 비보안 프로토콜(HTTP)에 있기 때문에 HMAC-SHA1을 사용해야 합니다.

    1) Signature 기본 문자열 생성

    • 서명을 만들기 위해서는 우선적으로 Signature 기본 문자열을 생성해야 합니다. 요청은 다음 파라미터(oauth_signature 제외)를 포함합니다.
      oauth_consumer_key
      dpf43f3p2l4k3l03 (컨슈머 키)
      oauth_token
      nnch734d00sl2jdk (Access 토큰)
      oauth_signature_method
      HMAC-SHA1 (서명 메소드)
      oauth_timestamp
      1191242096 (타임 스탬프)
      oauth_nonce
      kllo9940pd9333jh (nonce)
      oauth_version
      1.0 (OAuth 버전)
      file
      vacation.jpg (추가 파라미터)
      size
      original (추가 파라미터)
    • Signature 기본 문자열을 생성할 때 다음 입력들이 사용됩니다.
      • GET (HTTP 메소드)
      • http://photos.example.net/photos (파라미터를 제외한 절대 경로)
      • file=vacation.jpg
        &oauth_consumer_key=dpf43f3p2l4k3l03
        &oauth_nonce=kllo9940pd9333jh
        &oauth_signature_method=HMAC-SHA1
        &oauth_timestamp=1191242096
        &oauth_token=nnch734d00sl2jdk
        &oauth_version=1.0
        &size=original
    • 생성된 Signature 기본 문자열 (위의 3가지를 URL 인코딩한 후 &로 연결)

      GET&http%3A%2F%2Fphotos.example.net%2Fphotos&file%3Dvacation.jpg%26oauth_consumer_key%3Ddpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_token%3Dnnch734d00sl2jdk%26oauth_version%3D1.0%26size%3Doriginal

    2) Signature 값 계산

    • HMAC-SHA1로 base64 인코딩해서 다음의 Signature를 만들어 냅니다(text로는 Signature 기본 문자열을, key로는 kd94hf93k423kf44&pfkkdhi9sl3r4s00(컨슈머 시크릿 & 토큰 시크릿)를 사용).

      tR3+Ty81lMeYAr/Fid0kMTYa/WM=

    3) 보호된 리소스 요청

    • 결과적으로 컨슈머는 사진을 요청하기 위해 다음의 내용을 사용합니다.

      http://photos.example.net/photos?file=vacation.jpg&size=original
      Authorization: OAuth realm="http://photos.example.net/",
      oauth_consumer_key="dpf43f3p2l4k3l03",
      oauth_token="nnch734d00sl2jdk",
      oauth_signature_method="HMAC-SHA1",
      oauth_signature="tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D", (생성된 Signature를 URL 인코딩)
      oauth_timestamp="1191242096",
      oauth_nonce="kllo9940pd9333jh",
      oauth_version="1.0"

      이것을 쿼리 파라미터로 사용하면 다음과 같이 됩니다.

      http://photos.example.net/photos?file=vacation.jpg
      &size=original
      &oauth_consumer_key=dpf43f3p2l4k3l03
      &oauth_token=nnch734d00sl2jdk
      &oauth_signature_method=HMAC-SHA1
      &oauth_signature=tR3%2BTy81lMeYAr%2FFid0kMTYa%2FWM%3D
      &oauth_timestamp=1191242096
      &oauth_nonce=kllo9940pd9333jh
      &oauth_version=1.0

    • 사진 사이트는 이 서명을 확인하고 요청된 사진을 응답으로 보냅니다.



    출처 - http://dna.daum.net/apis/oauth/spec








    저작자표시

    'Security > OAuth' 카테고리의 다른 글

    OAuth 2.0 구현  (2) 2014.01.01
    OAuth 2.0 이해  (0) 2013.12.29
    OAuth  (0) 2012.05.22
    Posted by linuxism
    ,

    티스토리툴바