그러고 보니 바로 오늘(08/6/26)이 OAuth summit이 열리는 날이네요~ 좋은 결과 있기를~.
Disentangling delegation and authentication
OAuth가 인증 메커니즘을 위임하는데 있어서 의존도를 더 적게 명시할 수 있다면, 더 이해하기에 좋고, 구현하기 좋으며, 확장하기도쉬워질 것이다. 곧 있을 OAuth summit에서 OAuth 1.1혹은 2.0에서 이슈가 될 것을 기대해본다.
OAtuh 1.0은 4개의 튜플로 이루어진 핵심 데이터 모델을 가진다 :
token, token secret, consumer key, consumer secret
PLAINTEXT, HMAC-SHA1, and RSA-SHA1
이러한 구성 요소들이 다음과 같이 적시적소에 쓰인다면 전혀 문제 될 것이 없다 : Request(with 4-tuples) --> [algorithm] --> authentic request
그러나, 여러가지 예외사항들이 발생할 수 있다.
- request token을 요청했는데 아무런 token 혹은 token secret이 없을 때
- 사용자를 서비스로 리다이렉트 시킬 때, 사이닝(signed)이 되지 않은 요청일 경우
- PLAINTEXT 알고리즘은 항상 token과 token secret을 함께 보내는데, 한개의 item만 갈 수가 있다(즉, token secret은 없이 token만)
- RSA-SHA1 알고리즘은 token secret을 무시한다.
- RSA-SHA1 알고리즘은 별도의 consumer private RSA key가 있어서 consumer secret 이 필요가 없다.
- desktop app 나 javascript widget은 많은 사용자의 컴퓨터에서 돌아감에 따라 주어진 consumer secret을 보호하기 어렵기 때문에 그것을 사용할 수 없다.
- 등록을 취소한 app는 consumer key 혹은 consumer secret을 가지지 않는다.
- app와 service간에 어떤("2-way") 트랜잭션은 사용자에게 속한(behalf)것이 아니므로 token이나 token secret이 없다.
위에 제시한 각각의 예외사항은 충분히 일어날 수 있다. 그러나 이렇게 많은 예외를 위해 필요사항을 모델에 제안하는 것은 틀리다. 우리는 이러한 문제를 현명하게 나누지 않았다.
대안은 어떤 standalone 인증 알고리즘을 정의하는 것이다.
OAuth-RSA
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-RSA를 지원하도록 지시할 수 있다:
WWW-Authenticate: OAuth-RSA realm=...
how=uri,header,body what=header,body
클라이언트는 header 그리고/혹은 body의 RSA private key로 사이닝을 할 것이고, Authorization header나 query params혹은 body에 signature등을 넣어야할것이다.
OAuth-PLAIN
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-PLAIN을 지원하도록 지시할 수 있다: WWW-Authenticate: OAuth-PLAIN realm=...
how=uri,header,body
클라이언트는 Authorization header 혹은 query params 혹은 body에 oauth_secret파라미터를 포함시켜야 할 것이다.
OAuth-HMAC
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-HMAC를 지원하도록 지시할 수 있다: WWW-Authenticate: OAuth-HMAC realm=...
how=uri,header,body what=header,body
클라이언트는 headre 그리고/혹은 body에 message authentication code(MAC)을 계산하고, Authorization header 혹은 query params 혹은 body에 MAC등을 넣어야 할 것이다.
["what" indicates what parts of the request to sign;
"how" indicates how to incorporate the result into the request;
both could list all supported options]
이렇게 정의된 알고리즘은 특정 위임에 대한 것이 아니다. 이는 어떤 HTTP 요청에 대해서도 사용될 수 있다.
OAuth는 다른 알고리즘을 효율적으로 정의한다: 하위 요청을 통해 MAC을 계사하는데 사용되는 한개의 응답에 secret을 제공하는 것. 이는 특이한 메커니즘이다. 이처럼 동작하는 어떤 인증 스킴도 알지 못하지만, 이는 몇몇 보안상의 잇점을 제공한다. 이것에 대해서 생각하는 가장 좋은 방법을 찾았는데, 그것은 'crypto cookie'이다. 이는 하위 요청에 사용되어지는 일부(blob) 서버 응답의 표준 쿠키와 유사하다. 그러나 blob을 포함하는 것 대신에 그것을 직접적으로 노출하지 않고 당신이 blob을 알고 있음을 증명하는데 사용되는 MAC을 포함할 수 있다. 이러한 방식으로 우리는 4번째 인증 메커니즘을 정의할 수 있다.
OAuth-Crypto-Cookie서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth-Crypto-Cookie를 지원하도록 지시할 수 있다:
WWW-Authenticate: OAuth-Crypto-Cookie realm=... secret=...
how=uri,header,body what=header,body
클라이언트는 MAC key로 secret을 사용하고 OAuth-HMAC당 인증 요청을 해야할 것이다.
마지막으로 OAuth 전체적인 관점에서의 위임(delegation)이 있다.
나는 위임(delegation)에 대한 HTTP 인증 메커니즘을 분리하여 접근하는 것을 좋아한다.
OAuth
서버는 401 응답에 다음과 같은 헤더정보를 넣은 OAuth를 지원하도록 지시할 수 있다: WWW-Authenticate: OAuth realm=... authz=... access=...
how=uri,header,body
클라이언트는 authz URI로 사용자를 리다이렉트 시켜야 할 것이다(선택적으로 callback URI를 포함). 클라이언트는 Authorization 헤더, 혹은 query params혹은 body에 oauth_token을 포함시켜야할 것이다.
OAuth는 OAuth-PLAIN, OAuth-RSA, OAuth-HMAC, OAuth-Crypto-Cookie, 혹은 어떤 다른 인증 메커니즘(HTTPS와 함께 클라이언트 확인(certs); app에 대한 OpenID ...)과 묶여질 수 있다. OAuth는 oauth_token을 지원한다: 위임을 구별하기 위하 서버로부터 사용되는 blob. 그것은 요청의 여타의 요청에 사이닝 될 수 있다.
만약 token이 자동으로 일정기간마다 갱신될 필요가 있다면, "WWW-Authenticate: OAuth"헤더에 "token=..."어트리뷰트를 추가할 수 있다. 만약 "token"이 현재형이고, "authz"는 그렇지 않다면, 단지 존재하는 모든 oauth_token을 새로운 값으로 교체하면 된다. 만약 "authz"가 현재형이면, 사용자는 리다이렉트되어야만 할 것이다.
컨텐트 서버로부터 보안서버가 분리된 프로바이더는 위임(delegation)혹은 갱신이 요구될때면 언제든지 컨텐스 사이트에서 보안 서버로의 요청을 리타이렉트 시킬 수 있다. 보안 서버는 어떤 OAuth[-*] 메커니즘을 사요앟ㄹ 수 있고, 따라서 컨텐트 사이트로 돌려서 요청을 리다이렉트 한다.어떤 자세한 사항들이 겉보기에 그럴듯 하더라도, 어떤 인증을 풀어내는 컨셉과 위임(delegation)이 명료하기를 희망한다.
- James Manger
댓글을 달아 주세요