Web API認証方式のパターン
Web API認証の混沌
認証に成功しないとWeb APIを叩くことはできない。まずは認証である。
認証方法がWebサービスによって異なるというのはよくある話だ。Web APIの認証方式には標準化された様々な認証方式に加えて、実に多様なサービス固有の認証方式が存在する。
よってあるサービスを利用するにはまずそのサービスが提供している認証方式を理解する必要があるがこれがWeb API初心者にとって最初の関門となる。ここで躓いてPostmanをそっと閉じた人も少なくないだろう。
混沌を整理する
認証方式を以下の3パターンに分けてみよう。
まずはこれから取り組もうとしている認証方式が上記のどのパターンに当てはまるか判断することだ。そうすればどうすればよいか見えてくる。
標準化された方式であれば情報が豊富にあるはずだ。サービス固有の認証方式もAPIキー認証かForm認証か判別できれば8割方理解できたと言っても良い。
ここでは認証方式のパターンについて説明する。これらのパターンを理解しておけばWebサービスの認証方式の説明を読んだとき次になにをすればよいのか理解するのが早くなるだろう。
認証とはなにか
まず認証とはなにか。認証とは簡単に言えば「あなたがあなたであることを確認する」ことだ。
「認可」という用語もある。認可とは「あなたがその操作をする権限があるか確認する」ことだ。その過程で「あなたが誰か」知る必要があり、認証と同じような情報を必要する。このため両者が混同されたり、簡易的な認証として認可方式を利用したりすることがあるが根本的に別ものである。
1. 標準化されたHTTP認証方式
HTTPプロトコルで標準的に利用できる認証方式がRFCで複数標準化されている。以下にいくつか例を示す。
- Basic
- Digest
- Bearer
- OAuth
- Mutual
- RFC 8120
- サーバとクライアントが互いを認証する
- フィッシング対策として注目されたが現在ではあまり目にしない
- TSL Mutual Authenticationとは別ものなので注意
- Negotiate
- Anonymous
- 認証しない
動きは認証方式によって大きく異なるためここでは全体的な傾向のみ取り上げる。
標準化されているということもありこれらのプロトコルは広く使われている。そのため情報が豊富だ。情報不足で行き詰まるリスクは少ない。まずは検索してみよう。
これらの方式の中でもBasic、Digestなどはほとんどのサーバ、ブラウザでサポートされている。また動作がシンプルで実装するのも簡単だ。導入の障壁が最も低い認証方式である。
サービス固有の認証方式は独自ヘッダやメッセージボディを利用して認証することが多いのに対して、これらのプロトコルはRFCで定義されているWWW-AuthenticateヘッダやAuthorizationヘッダなどを使う。
全般的にセキュリティが低いものが多い。サービスでこれらの方式を採用する際はHTTPSと組み合わせて利用することを前提に検討することが好ましい。
あまり使われていないものもあるので全てを知っている必要はない。Basic、Digest、Bearer、OAuthを抑えておけばほとんどの場面で困ることはないだろうし、知らない方式を扱う場合も理解が早くなる。Basic、Digest、Bearer、OAuthについてはこちらの記事で簡単に紹介している。
なおRFC以外にもWebサービスの認証方式を標準化している団体が複数ある。
OASISが標準化したSAMLや、OpenID財団が標準化したOpenIDなどは広く使われている技術だ。両方ともSingle Sign Onを真剣に検討する際には無視できない技術だが「ちょっとWeb APIを叩く」という場面で登場する技術ではない。話をシンプルにするためにここでは取り扱うことを避けるがキーワードして覚えておいて損はない。
2. APIキー認証
事前に生成した強度の高い認証鍵をクライアントがRequest内に含めて送る認証方式全般を指す呼称だ。詳細はサービスによって異なる。例えばAmazonでは認証鍵をX-API-KEYヘッダに、Google Cloudでは認証鍵をkeyクエリ文字列に含める。AmazonやGoolge Cloudを始め様々なサービスで簡易的な認証手段として広く利用されている。
非常にシンプルに認証を実現できることがメリットだ。
シンプルな反面、安全性は低い。キーがあれば誰でも認証を通過できるため厳密には認証とは言い難い。またキーを盗聴されて盗まれる可能性もある。
安全ではないためRequest送信元に制限を設けることが一般的だ。IPアドレス、Refererヘッダ情報、アプリ種別（Androidアプリ、iOSアプリ等）などを元にアクセスを制限することができる。
複数の認証方式を用意し、APIキー認証ユーザには簡単な機能のみ開放し、より安全な認証方式（OAuth等）を利用するユーザに複雑な機能を開放しているサービス事業社が多い。
認証鍵はサービスの管理者ページで作成する。万が一、鍵が流出した場合には管理者ページで無効にすることができる。
鍵をユーザ単位で作成してユーザごとに認証する場合もあれば、サービスごとに作成してサービス単位で認証する場合もある。
3. Form認証、アクセストークン認証
APIキー認証と異なり認証鍵が動的に生成されて時間とともに変化する方式だ。このためAPIキー認証より安全性が高い。
- 動作
1つのアクセストークンで色々なサービスにアクセスできるようになっていることが多い（Google Sign-inなど）。Single Sign Onによく使われる。
アクセストークンをRedis等の高速なデータベースに格納して非常に高速なレスポンスを実現できる。
同じアクセストークンを利用する認証方式としてはHTTP認証方式のBearerとOAuthがある。Form認証方式を標準化したものがBearerとOAuthだと考えてよい。OAuthが手順1〜3までを担い、Bearerが手順4以降を担っている。
頭のいい人なら気づいたかもしれないがOAuthは正確には認証ではなく認可の仕組みだ。
