[OAuth]인증을 위한 오픈 스탠더드 프로토콜로

보안개발/구글 OAuth 2.0 API 2015. 4. 7. 14:43

728x90

1. 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 인증 방식을 사용하지 않지만 인증 절차에 대한 예시 정도로 생각해 주기 바란다.

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

그림 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 인증 과정을 그림으로 표현한 것이다.

그림 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을 요청하는 예이다.

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

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

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 방식을 사용한다.

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 필드를 아래와 같이 매개변수를 기준으로 정리했다.

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 입장에서는 핵심 기능을 더욱 공고히 하는 효과를 얻고 있다.

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

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

2. TISTORY OAuth 인증이란?

TISTORY는 Open API를 활용한 개발 도중 부분적으로 필요했던 "인증"의 불편함을 해소하고자 OAuth 2.0 프로토콜을 지원합니다.

1. Server-side flow (JSP, PHP) - Authorization code 방식

JSP/Servlet, PHP등과 같은 Server-side 프로그래밍으로 인증을 구현할 경우 사용하기 적합한 인증 방식입니다.

01. 인증에 필요한 티스토리의 인증 요청용 URL 2가지

· 인증요청 URL : https://www.tistory.com/oauth/authorize

· access_token 발급 요청 URL : https://www.tistory.com/oauth/access_token

02. 인증 요청 단계 (client -> Tistory)

티스토리에게 최초로 클라이언트(=컨슈머)가 인증을 요청합니다.

· URL : https://www.tistory.com/oauth/authorize

· Parameter :client_id : 등록시 발급받은 client_id
redirect_uri : 등록시 등록한 redirect_uri
response_type : "code" 라고 입력

· ex)https://www.tistory.com/oauth/authorize?client_id=abcdefghijklmnopqrstuvwxyz&redirect_uri=http://client.redirect.url&response_type=code

html 예)

<html>

<head>

<title>Tistory OAuth 2.0 JSP Sample - Example Authorization Code </TITLE>

</head>

<body>

<button type="submit">Request Athorization Code</button>

</form>

</body>

</html>

03. 인증 확인 및 Authorization code 발급 (Tistory -> client)

1. 1)티스토리가 클라이언트로 부터 1번단계인 인증 요청을 받으면, 등록되어 있는 client_id와 redirect_uri의 정보가
유효한지 확인한후, 유효하다면 즉시 User Login을 유도합니다.

2. 2)Login 성공과 함께 유저가 연결에 동의를 하면 Authorization code를 발급하고, 다음 단계를 기다립니다.

3. 3)발급은 클라이언트 등록시 입력한 redirect_uri 로 보냅니다.

· URL : http://${redirect_uri}/?code=${authorization_code}

· Parameter :code : 티스토리가 발급하는 Authorization code입니다.
이 값은 클라이언트가 Access Token을 받을때 까지 잘 유지 해야합니다.
이 code는 1시간 뒤 expire 되고, 한번 사용한 값은 재사용이 불가능합니다.

· ex)http://client.redirect.url?code=1234567890

· 만약 파라미터가 유효하지 않거나 여타 다른 오류가 발생할 경우 에러메세지를 redirect_uri에 실어 보냅니다.
자세한 명세는 '에러' 부분을 참조해주세요

04. 인증 허가 및 Access Token 발급 요청 단계 (client -> Tistory)

1. 1)티스토리는 최초 인증을 요청한 클라이언트가 유효한 클라이언트인지 검증을 합니다.

2. 2)발급한 code와 등록시 발급된 client_secret 이 유효한지 검증을 합니다.

3. 3)2번단계에서 받은 code 를 이 요청에 같이 실어 보내야합니다.

· URL : https://www.tistory.com/oauth/access_token

· Parameter :client_id : 등록시 발급 받은 client_id
client_secret : 등록시 발급 받은 client_secret
rediret_uri : 등록시 등록한 redirect_uri
code : 2번단계에서 발급받은 Authorization code
grant_type : authorization_code 라고 입력

· ex)https://www.tistory.com/oauth/access_token?client_id=abcdefghijklmnopqrstuvwxyz&client_secret=zxcvbnmasdfghjlk&redirect_uri=http://client.redirect.uri&
code=1234567890&grant_type=authorization_code

php 예)

<?php

$authorization_code = $_REQUEST['code'];

$client_id = '{발급받은 client_id를 입력}"';

$client_secret = '{발급받은 client_secret을 입력}';

$redirect_uri = '{등록시 입력한 redirect uri를 입력}';

$grant_type = 'authorization_code';

$url = 'https://www.tistory.com/oauth/access_token/?code=' . $authorization_code .

'&client_id=' . $client_id . '&client_secret=' . $client_secret .

'&redirect_uri=' . urlencode($redirect_uri) . '&grant_type=' . $grant_type;

$access_token = file_get_contents($url);

echo $access_token;

05. Access Token 발급 (Tistory -> client)

1. 1)티스토리는 client_secret과 redirect_uri 가 유효한지 검증을 합니다.

2. 2)또한 code는 재사용되지 않았는지, expire되지 않았는지도 확인을 합니다.

3. 3)기타 모든 항목값과 일치하게 되면 Access Token이 발급이 완료됩니다.

· URL : http://${redirect_uri}/?access_token=${access_token}

06. Access Token 획득

1. 1)티스토리로 부터 최종적으로 Access Token 을 발급받습니다.

2. 2)클라이언트는 반드시 이 토큰을 노출의 위험이 없도록 보안에 주의를 기울여야 합니다.

07. 에러

1. 1)만약 어떠한 상황이되었든 유저인증이나 에러가 발생하면 아래와 같이 응답합니다.

2. 2)에러가 발생하면 등록된 redirect_uri로 에러메세지를 실어서 보냅니다.

· URL : http://${redirect_uri}/?error=${error}&error_reason=${error_reason}

· Parameter :error : OAuth 2.0 명세에 정의된 error유형들에 대한 정해진 code값들입니다.
error_reason : 해당 에러에 대한 원인이나 이유입니다.

2. Client-side flow (Javascript, Desktop app) - Implicit Grant

Javascript 등을 이용해 클라이언트 브라우저등에서만 모든 처리가 이루어지는 요청에 활용할수 있습니다.

01. Authorization 요청 단계 (client -> Tistory)

1. 1)티스토리에게 최초로 클라이언트(=컨슈머)가 인증을 요청합니다.

2. 2)server-side flow와 비교하면 response_type 의 값만 다릅니다.

· 인증요청 URL : https://www.tistory.com/oauth/authorize

· Parameter :client_id : 등록시 발급받은 client_id
redirect_uri : 등록시 등록한 redirect_uri
response_type : "token" 이라고 입력

· ex)https://www.tistory.com/oauth/authorize?client_id=abcdefghijklmnopqrstuvwxyz&redirect_uri=http://client.redirect.url&response_type=token

html/javascript 예)

<html>

<head>

<title>Tistory OAuth 2.0 Sample - Example Implicit Grant </TITLE>

</head>

<body>

if (window.location.hash) {

alert(window.location.hash.substring(1));

}

</script>

<button type="submit">get access_token!</button>

<form>

</body>

</html>

02. AccessToken 발급 (Tistory -> client)

티스토리는 Implicit Grant 인증요청을 받으면 유저를 로그인을 할수있도록 유도 한 후
로그인에 성공하면, URL에 #access_token= 과 expires_in를 붙혀서 다시 Redirect 시킵니다.
expires_in 는 access_token의 만료시간을 뜻하며 초단위 입니다.

· URL : http://${redirect_uri}#access_token={$accss_token}&expires_in=3600

· ex)http://client.redirect.uri#access_token=1z2x3c4v5b6n7m8z

03. AccessToken 발급 (Tistory -> client)

티스토리로 부터 최종적으로 Access Token 을 발급받습니다. 브라우저의 URL로 바로 읽어 들일 수있으며,
클라이언트는 반드시 이 토큰을 노출의 위험이 없도록 보안에 주의를 기울여야 합니다.

-출처 : http://www.tistory.com/developer/oauth.php -

3. Naver OAuth

1.1. OAuth 소개

기존의 어플리케이션이나 웹 서비스에서는 자사의 기본 인증인 아이디와 비밀번호를 사용하여 사용자 인증을 수행하였습니다.
이러한 인증 방식은 어플리케이션을 제작하거나 웹 서비스를 하는 회사마다 서로다른 별도의 방법으로 사용자를 확인한 것입니다.
하지만 OAuth는 표준화인증 방식으로, OAuth를 이용하면, 이 인증을 공유하는 어플리케이션이나 웹서비스끼리의
별도의 인증이 필요가 없어지고, 개발자는 인증 절차의 복잡함을 해소할 수 있게 됩니다.

1.2. 기본 용어

네이버의 OAuth 인증 과정에서는 다음과 같은 용어를 사용하고 있으며, OAuth 인증 과정의 이해를 위해서 아래 용어에 대한
설명을 꼭 읽어보시기 바랍니다.

· • Service Provider(서비스 프로바이더)
API를 제공하는 서비스입니다. OAuth 인증을 지원하는 네이버의 각 서비스들이 서비스 프로바이더에 해당하며,
결국, 네이버가 서비스 프로바이더가 됩니다.

· • User(사용자)
서비스 프로바이더에 계정을 가지고 있는 서비스 사용자를 뜻하며, 통상적으로 네이버 계정을 가지고 있는 일반 사용자를 말합니다.

· • Consumer(컨슈머)
OAuth 인증을 사용하여 사용자 대신에 서비스 프로바이더에 접근을 하려고 하는 어플리케이션이나 웹 서비스를 뜻합니다.
주로 네이버 API를 사용하여 네이버 서비스에 접근하려고 하는 서드파티(제 3자)의 어플리케이션이나 웹 서비스입니다

· • Service(서비스)
OAuth 인증을 통해 사용자 데이터 등을 제공하는 서비스를 뜻합니다.

· • Consumer Key(컨슈머 키)
컨슈머(Consumer)에 부여되는 문자열 형태의 고유한 키로, 서비스 프로바이더는 이 키를 통해 컨슈머를 구분합니다.
또한 컨슈머의 입장에서는 자신을 증명하기 위한 서명문을 생성하기 위해 사용합니다.
컨슈머 키는 네이버 개발자 센터에서 발급 받을 수 있습니다.

· • Consumer Secret(컨슈머 시크릿)
컨슈머 키(Consumer Key)와 함께 발급하는 문자열 형태의 값으로 컨슈머가 컨슈머 키에 대한 소유권이 있는지를 검증하는 키입니다.
컨슈머 시크릿은 네이버 개발자 센터에서 발급 받을 수 있습니다.

· • Request Token(리퀘스트 토큰)
컨슈머가 사용자의 인증을 획득하는 과정에서 사용하는 값으로, 사용자 인증이 완료된 후에는 Access Token(액세스 토큰)으로 교환합니다.

· • Access Token(액세스 토큰)
컨슈머를 통해 보호된 자원(Protected Resource)에 접근하기 위한 서비스 프로바이더의 사용자의 인증 대신 사용하는 OAuth Token 값입니다

· • Token Secret(토큰 시크릿)
OAuth 인증 과정 중 Access Token이나 Request Token을 발급 받을 때 함께 발급되며, 컨슈머가 토큰의 소유권을 입증하는 키 값입니다.

· • Signature(시그니쳐, 서명)
컨슈머의 Oauth 인증 요청이 유효한 요청인지에 대한 검증값을 포함합니다. HMAC_SHA1 서명 메소드를 사용하여 생성합니다.

· • Signature Base String(서명 베이스 스트링)
시그니쳐를 생성하기 위해 사용하는 평문(Plain Text)입니다. Consumer Key, Token, Nonce, TimeStamp, Signature Method,
Version 등을 포함하여 생성합니다.베이스 스트링을 생성하는 방법은 [1.5 Signature Base String 생성 규칙]을 참고하세요.

· • Protected Resource(보호된 자원)
서비스 프로바이더에 존재하는 사용자의 데이터입니다. 예를 들어 네이버 포토 앨범의 사진이나 N드라이브의 데이터를 의미합니다.

1.3. OAuth 인증 Flow

네이버에서는 컨슈머가 효율적으로 네이버의 OAuth 인증을 수행할 수 있도록 다음의 2가지 방법을 통해 OAuth 인증을 제공하고 있습니다.

· A. 일반적인 OAuth 인증 형태

o • 컨슈머는 웹을 통해 서비스를 제공할 수 있어야 합니다.

o • 모든 인증 과정은 사용자의 웹 브라우저를 통해 진행이 되어야 합니다.

3. 서비스 프로바이더로부터
"인증되지 않은 Request Token"을
발급 받는 단계

4. 사용자가 직접 Request Token을 인증하는 단계 네이버 로그인 창을 통해 사용자는 로그인을 하고 컨슈머가 사용자의 보호된 자원에 접근할 것을 승인합니다.

5. "인증 된 Request Token"을 사용자의 보호된 자원에 접근할 수 있는 "Access Token"으로 교환하는 단계입니다.

o 컨슈머와 서비스프로바이더사이에서 자동으로 일어나는 단계입니다.

o 사용자가 직접 웹브라우저를 통해 사용하고 수동으로 조작하는 단계입니다.

o 인스톨한 애플리케이션

o 서비스 프로바이더 서버

10. 컨슈머가 서비스 프로바이더에게 Request Token을 요청합니다.

요청 파라미터 목록

§ oauth_consumer_key

§ oauth_signature_method

§ oauth_signature

§ oauth_timestamp

§ oauth_nonce

§ oauth_version (option)

§ oauth_callback

11. 서비스 프로바이더는 인증되지 않은 Request Token을 발급합니다.

응답 파라미터 목록

§ oauth_token

§ oauth_token_secret

§ oauth_callback_confirmed

12. 컨슈머는 사용자를 서비스 프로바이더(로그인 또는 승인화면)로 안내합니다.

요청 파라미터 목록

§ oauth_token (option)

13. 사용자가 인증을 하면, 서비스 프로바이더는 사용자를 컨슈머의 화면으로 안내합니다.

응답 파라미터 목록

§ oauth_token

§ oauth_verifier

14. 컨슈머가 서비스 프로바이더에게 Access Token을 요청합니다.

요청 파라미터 목록

§ oauth_consumer_key

§ oauth_token

§ oauth_signature_method

§ oauth_signature

§ oauth_timestamp

§ oauth_nonce

§ oauth_version (option)

§ oauth_verifier

15. 서비스 프로바이더는 Access Token을 발급합니다.

응답 파라미터 목록

§ oauth_token

§ oauth_token_secret

16. 컨슈머 Access Token을 사용하여 보호된 자원에 액세스 합니다.

요청 파라미터 목록

§ oauth_consumer_key

§ oauth_token

§ oauth_signature_method

§ oauth_signature

§ oauth_timestamp

§ oauth_nonce

§ oauth_version (option)

B. Application에서 사용하는 OAuth 인증 형태

o • Application은 사용자의 인증을 위해 웹 브라우저를 Application 내부에 포함하거나 외부로 작동시킬 수 있어야 합니다.

o • Application은 내부에 포함하거나 외부로 작동한 브라우저에 대한 제어 권한을 가져야 하며, 브라우저의 내용을 읽어올 수 있어야 합니다.

2. 컨슈머가 서비스 프로바이더에게
Request Token을 요청합니다.

3. 서비스 프로바이더는 인증 되지 않은
Request Token을 발급합니다.

4. 컨슈머는 사용자를 서비스 프로바이더
(로그인 또는 승인화면)로 안내합니다.

5. 사용자가 인증을 하면, PIN 값이 있는
페이지로 리다이렉션 합니다.

6. 컨슈머는 PIN을 가지고 서비스 프로바이
더에게 Access Token을 요청합니다.

7. 서비스 프로바이더는 Access Token을
발급합니다.

8. 컨슈머는 Access Token을 사용하여
보호된 자원에 엑세스 합니다.

o 컨슈머와 서비스프로바이더사이에서 자동으로 일어나는 단계입니다.

o 사용자가 직접 웹브라우저를 통해 사용하고 수동으로 조작하는 단계입니다.

o 어플리케이션의 내부적 호출입니다.

o 인스톨한 애플리케이션

o 웹 브라우저

o 서비스 프로바이더 서버

1.4. OAuth 인증을 위한 파라미터

다음의 파라미터는 OAuth 인증을 및 auth_signature 를 생성하기 위해 필요한 파라미터입니다. 이 파라미터들은 oauth_ 로 시작하는 형태의 이름을 사용합니다.

[표] OAuth 파라미터

파라미터 이름	설명	비고
oauth_callback	사용자가 Request Token에 대한 인증을 한 후 리다이렉트 할 웹 페이지의 URL입니다.
oauth_consumer_key	네이버 개발자 센터에서 발급 받은 Consumer Key 값입니다.	Consumer Key 값
oauth_nonce	컨슈머에서 생성하는 임의적인 문자열로 동일한 타임 스탬프에서는 유일한 값이어야 합니다.
oauth_signature_method	서명문을 생성하기 위해 사용하는 메소드입니다.	HMAC-SHA1 고정
oauth_timestamp	요청을 하는 시점의 타임 스탬프로, 1970년 1월 1일 00:00:00 GMT 부터 시작한 초 단위의 숫자입니다. 타임 스탬프의 값은 항상 이전에 사용한 타임 스탬프의 값보다 커야 합니다.
oauth_token	OAuth 인증 과정에서 서비스 프로바이더로부터 제공 받은 토큰 값입니다.	Request Token 또는 Access Token
oauth_version	OAuth의 버전 정보입니다.	1.0 고정
oauth_signature	위의 OAuth 인증 정보를 HMAC-SHA1 서명 후, Base64 인코딩 통해 생성한 서명 값입니다.
oauth_verifier	Callback URL에 대해 입증한 값

1.5. Signature Base String 생성 규칙

Signature Base String은 oauth_signature 서명 값을 생성하기 위해 먼저 만들어야 하는 문자열의 조합입니다. 이 문자열은 다음과 같은 형태로 이루어져 있습니다.

• {HTTP Request Method}&{Request URL}&{OAuth Parameters}

· A. HTTP Request Method

HTTP Request Method는 요청할 때 사용하는 HTTP Method를 말하며, 네이버 OAuth 인증에서는 GET과 POST 두 가지 방법을
지원합니다. GET과 POST는 대문자로 사용하여야 하며, RFC3986에서 정의한 퍼센트 인코딩 방법을 사용하여 인코드 해야 합니다.

· B. Request URL

일반적으로 인증 요청 시 사용하는 Request URL입니다. 하지만, 네이버 인증 시스템 상에서는 실제 API를 호출할 때
사용하는 Request URL 대신, 네이버 OAuth 자체의 URL을 사용합니다.네이버의 OAuth용 Reqeust URL은 다음과 같습니다.
• https://nid.naver.com/naver.oauth
이 Request URL을 퍼센트 인코딩을 하면 다음과 같습니다.
• https%3A%2F%2Fnid.naver.com%2Fnaver.oauth

· C. OAuth Parameters

요청을 위해 전달하는 OAuth 파라미터들 중 oauth_signature 를 제외한 파라미터 들입니다. 파라미터들은 파라미터의 이름
순으로 정렬을 해야 하며, 파라미터의 Name과 Value는 퍼센트 인코딩 해야 합니다.
urlencode(oauth_callback)=urlencode(http://www.example.com)&urlencode(oauth_consumer_key)=urlencode(YNR3Vze...)
&...의 형태로 작성이 되어야 합니다. 이 파라미터는 Signature Base String 생성에 사용하는 파라미터이며,
서비스 프로바이더로의 요청 파라미터가 아님을 주의하세요. 작성된 파라미터 리스트들(&로 묶여있는) 한번 더 RFC3986에서
정의한 퍼센트 인코딩 방법을 사용하여 인코드 합니다.

· D. Signature Base String의 조합

A, B, C에서 만든 각각의 결과물을 Signature Base String의 규칙에 맞게 조합을 합니다. 아래의 코드는
Signature Base String의 예시입니다.

GET&https%3A%2F%2Fnid.naver.com%2Fnaver.oauth&oauth_callback%3Dhttp%253A %252F%252Fnid.naver.com%252Ftest%252Ftestoauth.nhn%26oauth_consumer_key% 3DKdvYJ16Q_2yL%26oauth_nonce%3D7BE23CFD-B3D5-4DB3-A8D0-4B236366D03C% 26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1306930668% 26oauth_version%3D1.0

· E. HMAC-SHA1서명을 위한 키 생성

HMAC-SHA1 서명을 하기 위해서는 서명 키를 만들어야 합니다. 서명 키는 네이버 개발자 센터에서 발급 받은 Consumer Secret과
OAuth 인증 과정에서 서비스 프로바이더가 발급한 Token Secret을 다음과 같은 형태로 만들어 사용합니다.
• consumer_secret&token_secret
OAuth 인증 과정에서 Request Token 을 요청하는 단계에서는 발급받은 Token Secret이 없기 때문에 다음과 같은 형태로
서명키를 만듭니다.
• consumer_secret&

· F. HMAC-SHA1 서명을 통해 oauth_signature 값 생성

D 과정에서 생성한 Signature Base String을 E 과정에서 만든 키를 사용하여 HMAC-SHA1 알고리즘으로 서명을 한 후, Base64로 인코딩을 합니다. 그 결과 값을 oauth_signature 라는 OAuth 파라미터 값으로 사용합니다.

· G. 샘플 코드 – Java

@Override protected String getSignature(String baseString) throws OAuthException { try { String signature = base64Encode(computeSignature(baseString)); return signature; } catch (GeneralSecurityException e) { throw new OAuthException(e); } catch (UnsupportedEncodingException e) { throw new OAuthException(e); } } ... ... ... private byte[] computeSignature(String baseString) throws GeneralSecurityException, UnsupportedEncodingException { SecretKey key = null; synchronized (this) { if (this.key == null) { String keyString = OAuth.percentEncode(getConsumerSecret()) + '&' + OAuth.percentEncode(getTokenSecret()); byte[] keyBytes = keyString.getBytes(ENCODING); this.key = new SecretKeySpec(keyBytes, MAC_NAME); } key = this.key; } Mac mac = Mac.getInstance(MAC_NAME); mac.init(key); byte[] text = baseString.getBytes(ENCODING); return mac.doFinal(text); } ... ...

· H. 샘플 코드 - PHP

class OAuthRequest { protected $parameters; protected $http_method; protected $http_url; public $base_string; public function build_signature($request, $consumer, $token) { $base_string = $request->get_signature_base_string(); $request->base_string = $base_string; $key_parts = array( $consumer->secret, ($token) ? $token->secret : "" ); $key_parts = OAuthUtil::urlencode_rfc3986($key_parts); $key = implode('&', $key_parts); return base64_encode(hash_hmac('sha1', $base_string, $key, true)); } public function get_signature_base_string() { $parts = array( $this->get_normalized_http_method(), $this->get_normalized_http_url(), $this->get_signable_parameters() ); $parts = OAuthUtil::urlencode_rfc3986($parts); return implode('&', $parts); } public function get_normalized_http_method() { return strtoupper($this->http_method); } public function get_normalized_http_url() { $parts = parse_url($this->http_url); $scheme = (isset($parts['scheme'])) ? $parts['scheme'] : 'http'; $port = (isset($parts['port'])) ? $parts['port'] : (($scheme == 'https') ? '443' : '80'); $host = (isset($parts['host'])) ? $parts['host'] : ''; $path = (isset($parts['path'])) ? $parts['path'] : ''; if (($scheme == 'https' && $port != '443') || ($scheme == 'http' && $port != '80')) { $host = "$host:$port"; } return "$scheme://$host$path"; } public function get_signable_parameters() { // Grab all parameters $params = $this->parameters; // Remove oauth_signature if present // Ref: Spec: 9.1.1 ("The oauth_signature parameter MUST be excluded.") if (isset($params['oauth_signature'])) { unset($params['oauth_signature']); } ... } ... class OAuthUtil { public static function urlencode_rfc3986($input) { if (is_array($input)) { return array_map(array('OAuthUtil', 'urlencode_rfc3986'), $input); } else if (is_scalar($input)) { return str_replace( '+', ' ', str_replace('%7E', '~', rawurlencode($input)) ); } else { return ''; } } ...

2. Naver OAuth 인증하기

2.1.컨슈머 등록

OAuth 인증을 이용하기 위해서는 컨슈머 등록이 필요합니다.
이 과정에서 OAuth 인증을 위한 Consumer Key와 Consumer Secret은 네이버 [개발자 센터 > 오픈 API > oAuth > 컨슈머키 등록]
페이지에서 발급 받을 수 있습니다. 컨슈머 키 등록 페이지에서 이름, 설명, 로고 이미지, 이메일 주소, 사용 서비스,
서비스 형태, 서비스 URL, Callback URL 의 필드에 해당하는 내용을 입력 합니다. 그리고 oAuth 인증 약관 내용을 꼼꼼히 살펴 보시고
서비스 이용 약관에 동의 하셔야 컨슈머 키를 발급 받을 수 있습니다. 이용 약관에 동의 후 등록 버튼을 클릭하면
[컨슈머키 관리 > 상세보기] 페이지에 Consumer Key 와 Consumer Secret이 발급이 되었을 것입니다. 발급된 키들을 사용하여
OAuth 인증을 수행할 수 있습니다.

2.2. Request Token 발급

Request Token 발급 과정은 OAuth 인증 과정의 가장 첫 번째에 해당하는 과정입니다. 컨슈머가 Request Token 발급 과정을 거치면
“인증 되지 않은 Request Token”을 발급 받습니다. Request Token은 향후 사용자의 인증 과정을 거쳐 사용자의 보호된 자원에
접근할 수 있는 Access Token으로 교환하게 됩니다.Request Token은 영구히 저장되는 값이 아니며, 일정 시간이 지나면 폐기됩니다.

· A. 요청 URL
https://nid.naver.com/naver.oauth

· B. Protocol
HTTPS

· C. HTTP Method
GET / POST

· D. 요청 파라미터(Request Parameters)

파라미터 이름	설명	비고
mode	네이버의 OAuth 인증 단계의 구분은 mode의 파라미터 값으로 구분합니다. Request Token 발급 : req_req_token 사용자 인증 : auth_req_token Access Token 발급 : req_acc_token	req_req_token 고정
oauth_callback	사용자가 Request Token에 대한 인증을 한 후 리다이렉트 할 웹 페이지의 URL입니다.
oauth_consumer_key	네이버 개발자 센터에서 발급 받은 Consumer Key 값입니다.	Consumer Key 값
oauth_nonce	컨슈머에서 생성하는 임의적인 문자열로 동일한 타임 스탬프에서는 유일한 값이어야 합니다.
oauth_signature_method	서명문을 생성하기 위해 사용하는 메소드입니다.	HMAC-SHA1 고정
oauth_timestamp	요청을 하는 시점의 타임 스탬프로, 1970년 1월 1일부터 시작한 초 단위의 숫자입니다. 타임 스탬프의 값은 항상 이전에 사용한 타임 스탬프의 값보다 커야 합니다.
oauth_version	OAuth의 버전 정보입니다.	1.0 고정
oauth_signature	위의 OAuth 인증 정보를 HMAC-SHA1 서명 후, Base64 인코딩을 통해 생성한 서명 값이며, Signature Base String 작성 규칙에 의해 만듭니다.

· E. 응답 파라미터(Response Parameters)

파라미터 이름	설명	비고
oauth_token	추후 인증에 필요한 Request Token 값입니다.
oauth_token_secret	추후 인증에 필요한 Request Token Secret이며, Request Token의 소유권을 입증하기 위해 사용합니다.
oauth_callback_confirmed	callback 값이 정상적으로 접수 되었다는 것을 의미합니다.	true 또는 false

· • 형태 : oauth_token=OAUTH_TOKEN&oauth_token_secret=OAUTH_TOKEN_SECRET&oauth_callback_confirmed=true

2.3. Auth Request Token

2.2 단계를 통해 “인증되지 않은 Request Token”을 발급 받은 상태에서 컨슈머는 사용자가 직접 인증을 할 수 있도록
서비스 프로바이더의 인증 페이지로 Redirect 합니다. 사용자는 네이버 로그인 창을 통해 로그인을 수행한 후 컨슈머의 서비스가
사용자의 보호된 자원에 접근할 수 있도록 승인(또는 동의)을 합니다. 하단의 네이버 로그인 페이지 및 컨슈머의 접근을
허용하는 페이지 그림을 참고하세요.

그림1. 네이버 로그인 페이지

그림2. 컨슈머 사용자의 보호된 자원으로 접근을 허용 또는 거절하는 단계의 페이지

· A. 요청 URL
https://nid.naver.com/naver.oauth

· B. Protocol
HTTPS

· C. HTTP Method
GET/POST

· D. 요청 파라미터(Request Parameters)

파라미터 이름	설명	비고
mode	네이버의 OAuth 인증 단계의 구분은 mode의 파라미터 값으로 구분합니다. Request Token 발급 : req_req_token 사용자 인증 : auth_req_token Access Token 발급 : req_acc_token	auth_req_token고정
oauth_token	2.2 단계에서 발급받은 “인증되지 않은 Request Token” 입니다.

· E. 응답 파라미터(Response Parameters)

사용자가 인증을 수락하면 oauth_callback 으로 지정한 URL로 아래의 응답 파라미터를 포함하여 전송합니다.

파라미터 이름	설명	비고
oauth_token	사용자의 인증을 받은 Reqeust Token 입니다.
oauth_verifier	Callback URL에 대한 입증 값	oauth_verifier값은 Access Token을 요청할 때 포함해야 하는 값입니다.

• 형태 : http://myapp.example.com/callback/callback.nhn?oauth_token=REQUEST_TOKEN&oauth_verifier=VERIFIER_CODE

2.4. Access Token 요청

2.3 단계에서 사용자의 인증과 토큰 발급에 대한 동의를 받았습니다. “사용자의 승인을 받은 Request Token”을 사용하여
사용자의 보호된 자원으로 접근할 수 있는 자격을 가진 Access Token을 발급 받는 과정을 거쳐야 합니다. 이 Access Token을
이용하면, 네이버에서 제공하는 API를 사용할 수 있게 됩니다

· A. 요청 URL
https://nid.naver.com/naver.oauth

· B. Protocol
HTTPS

· C. HTTP Method
GET/POST

· D. 요청 파라미터(Request Parameters)

파라미터 이름	설명	비고
mode	네이버의 OAuth 인증 단계의 구분은 mode의 파라미터 값으로 구분합니다. Request Token 발급 : req_req_token 사용자 인증 : auth_req_token Access Token 발급 : req_acc_token	req_acc_token고정
oauth_consumer_key	네이버 개발자 센터에서 발급 받은 Consumer Key 값입니다.	Consumer Key 값
oauth_token	2.3 단계에서 발급받은 “인증 받은 Request Token” 입니다.
oauth_signature_method	서명문을 생성하기 위해 사용하는 메소드입니다.	HMAC-SHA1 고정
oauth_timestamp	요청을 하는 시점의 타임 스탬프로, 1970년 1월 1일부터 시작한 초 단위의 숫자입니다. 타임 스탬프의 값은 항상 이전에 사용한 타임 스탬프의 값보다 커야 합니다.
oauth_nonce	컨슈머에서 생성하는 임의적인 문자열로 동일한 타임 스탬프에서는 유일한 값이어야 합니다
oauth_version	OAuth의 버전 정보입니다.	1.0 고정
oauth_verifier	Callback URL에 대해 입증한 값
oauth_signature	위의 OAuth 인증 정보를 HMAC-SHA1 서명 후, Base64 인코딩을 통해 생성한 서명 값이며, Signature Base String 작성 규칙에 의해 만듭니다.

· E. 응답 파라미터(Response Parameters)

사용자가 인증을 수락하면 oauth_callback 으로 지정한 URL로 아래의 응답 파라미터를 포함하여 전송합니다.

파라미터 이름	설명	비고
oauth_token	사용자의 보호된 자원에 접근하기 위해 사용할 Access Token 값입니다.	req_acc_token고정
oauth_token_secret	인증에 필요한 Access Token Secret이며, Access Token의 소유권을 입증하기 위해 사용합니다.
userid	해시 함수로 변환한 네이버 아이디 정보입니다.

• 형태 : oauth_token=OAUTH_TOKEN&oauth_token_secret=OAUTH_TOKEN_SECRET&id=enc(naverID)

2.5. Access Token을 사용하여 보호된 자원으로의 접근

발급 받은 Access Token은 앞으로 사용자의 인증을 대신할 것이고, Open API를 사용하기 위한 인증 값으로 사용됩니다.
그리고 OAuth 파라미터들은 인증을 위해서 Authorization Header 라는 형태로 변환이 되어 HTTP Header에 포함해야 합니다.

· A. Authorization Header 작성

다음은 작성 된 Authorization Header의 예시입니다.

Authorization: OAuth realm="http%3A%2F%2Fnid.naver.com%2Fnaver.oauth", oauth_consumer_key="dpf43f3p2l4k3l03", oauth_token="nnch734d00sl2jdk", oauth_signature_method="HMAC-SHA1", oauth_timestamp="137131202", oauth_nonce="chapoH", oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"

o • Authorization Header는 Authorization 이라는 이름을 HTTP Header를 성정해야 합니다.

o • 위의 예시에는 가독성을 위해 줄바꿈을 하였으나, Authorization Header는 한 줄로 작성해야 합니다.

o • 헤더의 시작은 “OAuth “ 로 지정하며, 공백 문자까지 포함하여 총 6글자이어야 합니다.

o • 이후 추가되는 OAuth 파라미터들은 Name=”Value”의 형태이어야 하며 Name과 Value는 RFC3986에 의한 퍼센트 인코드 방법으로 인코딩이 되어야 합니다. 그리고 Value의 양 옆에 쌍 따옴표를 표기합니다.

o • Name과 Value의 쌍은 각각 쉼표(,)로 구분합니다.

o • realm은 realm="http%3A%2F%2Fnid.naver.com%2Fnaver.oauth" 의 형태로 지정합니다.

o • oauth_token은 2.4 과정을 통해 발급받은 Access Token 입니다.

o • oauth_signature는 Signature Base String 생성 규칙에 의해 작성된 값입니다.

3. Appendix

3.1. RFC3986 퍼센트 인코딩(%XX)

OAuth의 모든 파라미터 이름과 값들은 RFC3986에서 정의한 Percent-Encoding(%XX) 방법으로 Escape해야 합니다.
다음은 RFC3986 퍼센트 인코딩에 대한 스펙입니다.

· • 모든 텍스트의 이름과 값은 Percent-Encoding 이전에 UTF-8로 인코딩이 되어 있어야 합니다.

· • RFC 3986의 Section 2.3에서 정의한 예약되지 않은 문자는 인코딩 해서는 안됩니다.

예약되지 않은 문자: 알파벳(A~Z, a~z), 숫자(0~9), -(hyphen), . (period), _(underscore), ~(tilde)

· • 위의 예약되지 않은 문자 이외의 모든 다른 문자들은 Percent-Encoding 방법으로 인코딩 해야 합니다.

· • 16진수의 문자는 대문자로 치환되어야 합니다.

3.2. Nonce와 Timestamp

OAuth 인증 과정에서, 네이버 OAuth 인증 시스템의 리소스 소모 공격에 대한 방어 매커니즘으로 Nonce와 Timestamp를 상호 비교하는 로직이 포함되어 있습니다.
따라서 컨슈머는 다음에 유의하여 Nonce와 Timestamp를 전달해야 합니다.

· • Nonce는 유일한 값이어야 합니다. 동일한 어플리케이션에서 중복된 Nonce가 발급이 된다면,
인증에 실패할 경우가 발생할 수 있습니다.

· • Timestamp는 Unix Timestamp를 사용합니다. 검증이 이루어지는 곳은 네이버의 인증 서버이기 때문에,
컨슈머의 서버(또는 클라이언트)는 표준시에 최대한 근접하게 설정이 되어야 합니다.

3.3. 이용자 약관 동의 및 법정 대리인을 통한 약관 동의

네이버 OAuth 인증은 네이버 개인 정보 취급 방침(http://www.naver.com/rules/privacy.html)에 의거하여,
사용자 정보에 대해 “제 3자 정보 제공 동의”에 대한 내용을 고지하여야 하며, 사용자로 하여금 약관에
동의한다는 내용을 전달 받아야만 OAuth 인증을 진행할 수 있습니다. 14세 미만의 이용자의 경우 법정 대리인을
통한 이용 약관 동의가 있어야 하며, 필요하다면, 컨슈머의 어플리케이션 또는 웹 서비스에서 해당 내용에
대한 안내가 추가될 수 있습니다.

-출처 : http://dev.naver.com/openapi/apis/oauth/guide-

728x90

저작자표시

'보안개발 > 구글 OAuth 2.0 API' 카테고리의 다른 글

oAuth에 대해서 (0)	2015.04.07
Facebook 연동 - API Error Description: Invalid OAuth 2.0 Access Token (0)	2015.04.07
OAuth 2.0 관련 정보 (0)	2015.04.06
구글 OAuth 2.0 API 참조 링크 (0)	2015.04.02

nineDeveloper

안녕하세요 현직 개발자 입니다 ~ 빠르게 변화하는 세상에 뒤쳐지지 않도록 우리모두 열심히 공부합시다 ~! 개발공부는 넘나 재미있는 것~!

160x600