Amazonの人が提案するDistributed OAuthという提案仕様

AnazonのDick Hardt氏が「Distributed OAuth」という仕様を提案している。

昨年行われたIETF100でも議論があり、来週行われるOAuth WG Virtual Meetingでも話が進められるようだ。

遅らせばながら簡単に読んで見る。

Distributed OAuthとは

通常のOAuth2では、一つのリソースサーバと一つの認可サーバがあり、その関係は固定的です。この提案仕様では、もっと複雑で大きなケースを想定しています。
同様の機能を持つ複数のリソースサーバと、リソースサーバごとに別の認可サーバがあるようなケースです。

IETF100の発表資料を見るとイメージは湧きやすいでしょう(あくまで例だと思います)
f:id:ASnoKaze:20180108010721p:plain
https://datatracker.ietf.org/meeting/100/materials/slides-100-oauth-sessa-distributed-oauth/

Distributed OAuthでは、クライアントがリソースの認可を行う認可サーバをリソースサーバに問い合わせることで、そのリソースサーバと関連する認可サーバを知れるようにする提案仕様です。

Distributed OAuthフロー

f:id:ASnoKaze:20180108011422p:plain

  • (A) クライアントは認可サーバを見つけるために、Authorizationヘッダをつけずリソースサーバにリクエストを送信する (この時TLS通信で得られた証明書から、hostを取得しておく)
  • (B) リソースサーバは401レスポンスを返す。WWW-Authenticateヘッダのissトークンを発行する認可サーバのエンドポイントを指定する
       HTTP/1.1 401 Unauthorized
       WWW-Authenticate: Bearer realm="example_realm",
                                iss="http://issuer.example.com/token",
                                scope="example_scope",
                                error="invalid_token"
  • (C) クライアントはissで指定されたURLにアクセストークンリクエストを送信する
       POST /token HTTP/1.1
       Host: issuer.example.com
       Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
       Content-Type: application/x-www-form-urlencoded

       grant_type=client_credentials
       &scope="example scope"
       &host=resource.example.com
       &realm="example_realm"
  • (D) 認可サーバはhost属性を持つアクセストークンを払い出す際に、
  • (E) クライアントは保護されたリソースにアクセストークンを持ってアクセスする
  • (F) リソースサーバはそのアクセストークンのhost属性がリソースサーバのhostであることを検証を行い、保護されたリソースへの処理をおこないます。

攻撃モデル

このDistributed OAuthでは、幾つかの攻撃モデルについて検討しています。

  • 悪意あるリソースサーバがクライアントから得たアクセストークンを再利用し、別のリソースサーバにアクセスする
  • 悪意あるリソースサーバは、異なるリソースサーバーで使用できるアクセストークンを取得するようにクライアントに指示しアクセストークンを取得する
  • 悪意あるリソースサーバは、悪意ある認可サーバにクライアントをリダイレクトし、クライアントからの情報を取得する

host属性を検証する、mutual TLS・proof of possion認証で上記の問題は緩和できるらしい...