APIにおける認証情報の取り扱い

多くのAPIが認証情報とともに実行されます。実行ユーザを特定する目的の場合もあれば、APIキーのような情報を使ってコール数をカウントする目的で使うこともあります。

今回はそんなAPIにおける認証情報をAPI中のどこに持たせるのが良いか、紹介します。

URLパラメータ

URLのパラメータとして持たせる場合はセッションキーやトークン文字列であることが多いです。もう一つのパラメータ（アプリケーションキーなど）と合わせて、認証が正しいことを検証するようになっています。

トークン文字列は一定期間で切れる仕組みになっており、有効期限が過ぎた後はリフレッシュして新しいトークン文字列を取得し直します。

URLの場合、Webブラウザからの検証がしやすいのがメリットです。単純にURLをブラウザで開いて結果が返ってくればパラメータが正しいかどうかが確認できます。

HTTPヘッダー

HTTPヘッダーに認証キーを埋め込む方法もよく見られます。Webブラウザからの確認は若干難しくなりますが、Ajaxのような仕組みを使えばヘッダーに文字列は簡単に追加できます。

クエリー文字列はどういった操作を行うか指定するものとし、ヘッダーは認証などシステムのスコープを分けるのは開発者にとって分かりやすい区分けかも知れません。

セッション、クッキー

あまりお勧めしませんがセッションやクッキーに認証情報を持たせることがあります。スマートフォンアプリなどで、非公開な自社アプリ限定で使っているAPIの場合、このようなケースがあります。

利点としては既存のWebサービスと同じ仕組みで使いまわせるという点が挙げられます。Webサービスでは認証情報をURLに載せたりしません。ヘッダーにするとWebブラウザからは利用できなくなります。

WebサービスとAPIは分けて提供する方が良いのですが、Webサービス側で認証を通っているにも関わらずAPI側の認証が通っていないと判断されるのはユーザビリティが良くありません。そのため、セッションキーを利用するケースも少なからず存在します。

お勧めな方法は？

OAuth2ではURLに認証トークンを追加する方法になっています。実装としては一番手軽と言えるかも知れません。次にヘッダーへの追加が良いでしょう。セッションを用いるのはよほどのことがない限り避けるのが良いでしょう。

Webサービスとの連携についていえば、セッションの認証キーとAPIの認証トークンとを交換するAPIを用意するのが良さそうです。まず、そこにアクセスすることでAPIアクセスに使える認証トークンが手に入ります。その後からのアクセスは認証トークンを使えば良いのです。認証トークンはオンメモリに保存し、別なURLに移動した際には再度交換すれば良いでしょう。認証トークンは重要な情報なのでlocalStorageに保存するのは避けた方が良いでしょう。

認証トークンは定期的にアップデートしましょう

認証トークンは1週間程度の有効期限が良いかと思います。多くのスマートフォンアプリでは認証トークンをアプリ内にストアし、それを使い続けます。しかし万一認証トークンが漏洩した場合、誰でもそのサービスへなりすましでアクセスできるようになってしまいます。

認証トークンをアプリ内にストアするのは致し方ありませんが、アプリの起動時に新しいものと差し替えても良いでしょう。そして認証トークンは複数の端末からは使えないように制御するのが良いでしょう。そのため1ユーザに対して複数の認証トークンが保存できるようになっているのがお勧めです。

APIにおける認証トークンは認証情報そのものです。漏洩すると、APIを経由してデータ操作が自由にできるようになってしまいます。それだけに漏洩しづらい場所に保存したり、使い方にも注意が必要でしょう。

どのアプリ、どのブラウザまたはシステムからアクセスしたかが分かるように、認証トークンは複数発行できるようにしましょう。そうしてユーザから任意のタイミングでトークンを削除したり、再生成し直せるようになっていると便利ではないでしょうか。