오픈API는 매우 쉬운 기술이다. 오히려 어려워선 안될 기술이다. 오픈API는 기술을 활용하기 위한 도구이기 때문이다. 도구가 어렵다면 아무리 좋은 기술도 효용가치가 없다. 하지만 어쩔수 없이 어렵게 변할때가 있다. 인증이 포함된 경우가 그런 경우다.
인증을 이용하는 대표적인 예는 아마존 웹 서비스(이하 AWS)와 국내 Daum 블로그 API가 있다. 두가지 경우 모두 인증방식은 동일하다. AWS에서 제공하는 인증 문서를 통해 인증방식의 기본 원리를 살펴보도록 하자.
인증의 기본은 인증키와 비밀키로 구성된다. AWS에서는 이를 Access Key ID, Secret Access Key라 지칭하며 Daum 오픈API에선 인증키, 서명키로 지칭한다.
여기서 중요한 점은 비밀키의 경우 어떠한 경우에도 외부에 유출되어선 안된다는 점이다. 비밀키는 개발자(You)와 서비스 제공자(AWS)만이 알고 있는 비밀번호와 같다. 따라서 유출될 경우 인증을 가로채기당할 수 있다. 만약 유출되었다고 판단될 경우 비밀키를 초기화하고 재발급 받을 수 있다.

인증을 포함해 요청하는 방법은 원리만 알면 그다지 어렵지 않다. 요청에 필요한 파라미터에 비밀키(Secret Access Key)를 덧붙여 메시지 인증 알고리즘인 HMAC 암호화로 서명(Signature)을 생성해 요청을 보내면 된다. 개발자가 어렵게 생각하는 부분은 HMAC 암호화 부분인데 각 언어별 라이브러리가 있으니 이를 이용하면 된다.

요청을 받는 쪽(AWS)은 인증키(Access Key ID)를 통해 비밀키(Secret Access Key)를 알아낸 후 이를 다시 요청자와 같은 방법으로 서명을 생성해 이것이 요청자의 서명과 동일한지 판별한다. 동일할 경우 인증이 허용되며 동일하지 않을 경우 인증이 실패한 것으로 간주한다.
여기서 중요한 점은 서명의 경우 OTP(One-Time Password) 형식을 따른다. 즉, 한번 사용된 경우 효력을 상실한다. 또한 서명값을 생성할때 쓰는 파라미터 중 Timestamp값이 있어 매초단위로 서명값이 변한다. Daum 인증API의 경우 여기에 5자리의 난수를 생성해 덧붙이는데 이론적으로 매초당 10만번의 유일한(unique) 요청을 보낼 수 있다.
서명값의 유효기간은 AWS의 경우 15분이다. 15분이 지난 서명값은 Timeout 처리되며 유효하지 않은 것으로 판별한다. 즉, 발급된지 15분 이내의 한번도 사용하지 않은 서명값만 유효한 것으로 처리한다.



10 comments
Trackback URI: http://www.likejazz.com/archives/282/trackback/
Pingback from Daum 개발자 네트워크 » Blog Archive » 오픈API 인증 원리
April 14th, 2008 at 5:39 pm
Trackback from Hopangbear’s Story - [펌] 오픈API 인증 원리
April 21st, 2008 at 1:21 pm
Pingback from likejazz.COM · 옥션 해킹으로 되돌아본 오픈API와 보안
April 21st, 2008 at 11:08 pm
잘 봤습니다.^^
그런데 AWS가 어떻게 공개키로 개인키를 알아낼 수 있는지 궁금하네요.
제가 설명이 조금 부족했던것 같네요. AWS는 개인키를 발급한 주체이며 기본적으로 공개키, 개인키를 다 알고 있습니다. 이 자체는 암호화하지 않으며 데이타베이스등에 그대로 저장되어 있습니다. 그래서 AWS가 공개키를 받으면 조회해서 개인키를 알아낼 수 있습니다. 일반적으로 비밀번호는 그 자체도 암호화해서 저장하지만 개인키는 비밀번호와 달리 그대로 저장합니다. 왜냐면 서비스 제공자는 언제든 개인키를 꺼내올 수 있어야 하기 때문입니다.
개인키는 사용자(You)와 서비스 제공자(AWS), 단 둘만이 알고 있어야 하는 키이며 유출될 경우 언제든 다른 키로 재발급 받을 수 있습니다.
오픈API는 제가 잘 모르지만,
일반적으로 공개키/비밀키 기반의 암호화 인증은:
1. 원본 데이터==(비밀키)==>암호화된 데이터
2. 암호화된 데이터==(공개키)==>원본 데이터
의 두 가지만 인코딩만 가능합니다.
따라서, AWS는 공개키만 저장하고 있으면 될 텐데요.
ㄴㄴ님, 네 맞습니다. 그런 방식도 있습니다만 계산 비용(Computational cost)때문에 개인키를 나눠갖고 서로 암호화해서 일치 여부를 검증하는 기술이 널리 사용됩니다. 계산 비용이 훨씬 적게 듭니다.
공개키/비밀키 기반은
1. 원본데이터==(공개키)==>암호화된 데이터
2. 암호화된데이터==(비밀키)==>원본 데이터
인데요. ^ ^
그래서 오픈API의 경우 공개키/비밀키 구조와 매칭시키는건 맞지 않은것 같네요. 오픈API 설명에서 말씀하신 개인키의 경우 개인식별자 정도로 생각하는게 혼돈이 없지 않을까요?
전형적인 대칭키 기반의 인증방식인듯 하네요. ^ ^
수정합니다.
오픈API 설명에서 말씀하신 개인키의 경우 개인식별자 정도로 생각하는게 혼돈이 없지 않을까요?
==>
오픈API 설명에서 말씀하신 공개키의 경우 개인식별자 정도로 생각하는게 혼돈이 없지 않을까요?
무명님, 알려주셔서 감사합니다. 제가 조금 잘못 이해하고 있었네요. 공개/비밀키 방식은 상호 교환한 키를 통해 원본 데이타를 추출하는 방식이 맞습니다.
오픈API의 인증방식은 말씀하신대로 대칭키 기반의 인증방식으로 본문에서 용어를 인증키/비밀키로 수정하였습니다.