RESTful API の 認証の枠組

作者 Dilip Krishnan , 翻訳者 徳武 聡 投稿日 2010年1月26日

セクション

エンタープライズ・アーキテクチャ,

設計/アーキテクチャ

トピック

REST ,

SOA ,

ID管理 ,

セキュリティ ,

プログラミング ,

エンタープライズアーキテクチャ ,

Architecture

共有 |

原文(投稿日：2010/01/20)へのリンク

“誰もがカスタムの認証プロトコルの必要性を感じています。” とGeorge Reese氏は言う。この主張は、彼がクラウド事業者やSaasベンダのプログラミングAPIを使って仕事をしたことから学んだことのひとつだ。この記事で氏はすべてのREST認証が必要とする基準を提案している。

氏は多種多様なウェブサービスAPIを使って開発をしてきた。そして、それぞれのAPIで異なる認証の仕組みが必要になるのを経験している。

あるベンダAが要求しているのは、パラメータをURLエンコードする前の問い合わせにサインすることなのか、それともURLエンコードしたあとなのか。そんなことに頭を悩ませるのにもう疲れました。APIコールの認証をするのに対話式の証明が必要なAPIを提供しているベンダもあります。もううんざりです。

氏はREST APIの認証を設計するための基準のアウトラインを描いている。“単純にやろう。もしAPIのコールが暗号化されていなかったら、安全な呼び出しであるとを装うことすらできない。”、氏が言うには、

1. すべてのREST APIコールは信頼されたCAによってサインされた証明書を使ったHTTPSでおこなわれなければならない。すべてのクライアントはサーバとやり取りする前に証明書を検証しなければならない。

信頼された機関によってサインされた証明書を利用することで、SSLは"中間者攻撃"を防ぐことができます。中間者攻撃とは攻撃者がクライアントとサーバの間に入り込んで"暗号化された"トラフィックを盗聴する攻撃です。

もしサーバのSSL証明書を検証できなかったら、クライアントは、REST要求を誰が受け取るのかわからないということになります。

2. すべてのREST APIコールは認証コンポーネントと共有の秘密鍵で構成される専用のAPIキーを通して行われるべきである。システムは利用者が複数の有効なキーを保持することを許可し、個々のキーを簡単に無効できなければならない。

第一に重要なことは、REST要求をするシステムは対話可能なユーザではないということです。[…] RESTが認証するのはプログラムであってユーザではありません。したがって人間相手のID/パスワードの認証よりも強力な認証をおこなうことができます。

第二にRESTサーバは各利用者に対して複数のAPIキーをサポートするべきだ、ということです。こうすることで潜在的な情報漏洩の可能性を分離できますし、仮に漏洩が起こったとしても追跡が可能です。[…] 漏洩が起こった場合は、APIキーをいっきに置き換えるエレガントな方法も必要になるでしょう。

3. すべてのREST要求は、署名によって正式なものとして証明されている必要がある。署名は小文字のアルファベット順に並んだクエリパラメータに対してプライベートな証明書を表す署名トークンを使って行われる。署名は要求文字列をURLエンコーディングする前に行う。

言い換えると、要求をする際には要求の一部にAPIキーの共有鍵の情報を含める必要はなく、その代わりにその情報で要求に署名をする、ということです。要求は最終的には下記のようになるでしょう。

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

署名された文字列は"/object?apikey=Qwerty2010&timestamp=1261496500"となり、signatureはAPIキーのプライベートな部分を使って、この文字列に対してHMAC-SHA256ハッシュを行ったときの値です。

氏は、ほとんどのRESTlikeでRESTFulなAPIソリューションの中で、認証に関することは二の次にされていることを認めている。しかし、記事の結論部で、氏は読者に対して"誰かの例に倣うこと。自分独自の認証機構を広めようとしないこと”を強く勧めている。

ぜひこの勧めに従っていたただきたい。原文はO’Riellyコミュニティブログ見つかる。