API認証とは？ Wallarmによるガイド

APIにおける認証と認可

Web API認証について学ぶ前に、何でないかを確認してみましょう。 

まず、認証は認可と全く同じではありません。これらの用語は混同されがちですが、入れ替えて使用するのは誤りです。 

API認可は、利用者が許可された方法でAPIを使用できるようにする仕組みです。対象の利用者にその操作が認められているかどうかを判断します。例えば、第三者のAPI利用者にはソースコードの変更が許されず、そのためには管理者権限を持つ者が必要です。 

OAuthやAPI Keysなどの手段を用いることで、API開発者はどの利用者がどの操作を行えるかを決定できます。これにより、APIの利用を厳しく管理・監視することが可能になります。

アクセスが厳格な規則に従って行われるようにし、規定に反する場合はアクセスを許可しません。これは認証の後に続く段階です。 

効果的なAPIセキュリティのためには、利用者の認証手段が欠かせません。身元確認が完了した後、認可も戦略の一部となる必要があります。単独の認証手法だけでは十分ではありません。 

API認証は、APIセキュリティのさまざまな面に対応します。単体でも有効で、利用者が主張する人物であるかを確認します。 

この仕組みを最も簡単に説明すると、会社所有のリソースにアクセスする前に社員証や身分証明書を提示することに例えられます。 

API認証とは

先ほど、認証は認可と同じではないことが明確になりました。では、API認証とは何でしょうか？

つまり、許可されていないアクセスを防ぐために、利用者の身元を確認する手続きです。 

他国を訪れる際にパスポートを提示するのと同様に、API利用者は該当するAPIの利用を開始する前に、APIキーや類似の認証情報を提供して自らを確認する必要があります。 

これにより、API開発者は、認証済みまたは利用料を支払った利用者のみがこの強力なアプリ間通信手段にアクセスしていることを保証できます。複雑なエコシステムではAPIの利用状況を把握するのが難しいですが、API認証の実装によって各段階で利用者確認が自動化され、場合によっては不正なアクセスの防止にも役立ちます。 

一般的なAPI認証手法

次に、どのように認証が行われるのか、その方法を見ていきます。全体で4つ、世界的に容認されている手法があります。 

1. HTTPベーシック認証

おそらく最も古い認証手法であるHTTPベーシック認証は、各API利用者に固有のユーザー名とパスワードを提供するHTTPユーザーエージェントを利用します。APIに登録されると、HTTPユーザーエージェントはこれらの固有の認証情報を割り当てます。 

利用者はその情報を使ってAPIにログインできます。セッションIDやクッキー、煩雑なログイン手順は必要なく、すべてはHTTPヘッダーによりハンドシェイクが省略され、自動的に進行します。 

このHTTPヘッダーにより外部デバイスとの通信が可能となり、認証が成功した場合にのみ通信チャネルが確立されます。ベーシック認証により認証セッションが生成され、セッションIDが状態保持型のエコシステムでサービス提供を可能にします。簡単に感じられますね。

確かにシンプルですが、完璧とは言えません。終端間暗号化がなければ、MITM攻撃のリスクが高まり、熟練のハッカーに認証情報が盗まれる危険があります。 

この問題から、より改善されたAPI認証手法が求められるようになりました。 

2. OAuth認証

近代的なAPIセキュリティ手法であるOAuthは、API認可と認証の両方を統合し、セキュリティの壁を突破されにくくしています。そのため、Facebook、Google、Twitterといった企業が自社APIに採用しています。なお、必ずしも両方を同時に実装する必要はありません。 

認可のためだけにOAuthを導入することも可能です。機能の流れは以下の通りです。 

• ‍Step 1: 利用者がログインを開始。
• ‍Step 2: システムがトークン形式で認証要求を行う。
• ‍Step 3: 利用者がトークンを認証サーバへ送信する。
• ‍Step 4: サーバが定められた認証ルールに基づき要求を承認または拒否する。

表面上はシンプルですが、その背後では複雑なアルゴリズムが動作しています。トークンは非公開であるため、この手法でセキュリティは損なわれません。APIセキュリティの範囲や有効期限を定められる点から、多くの人に支持されています。 

現在、OAuth 2.0が主流であり、拡張もしやすくなっています。さらに、ワンレッグドやスリーレッグドといったバリエーションも存在します。機微なデータを扱わない場合は前者を、読み取り専用のデータの場合も同様に考慮してください。 

後者のスリーレッグドOAuthは、重要な情報を扱うAPIに適しており、主要な認証サーバ、APIサーバ、最終利用者の3者が関与します。 

OAuth単体でも効果的ですが、OpenID Connectと組み合わせることで、あらゆるAPIに対して非常に強固なセキュリティ体制を実現できます。これはアイデンティティ層で動作し、認証サーバ側で利用者の身元確認を補助します。 

3. APIキー認証 

API開発者は、API活用を迅速に始める最速の方法と捉えています。初期の認証手法の問題点に対する解決策としても現れ、導入が非常に簡単です。 

この方法では、固有の値が生成され、最初のログインセッションと組み合わせられます。以降のログイン時には、その値を入力することで認証が完了します。利用者のIP情報や一部のハードウェア情報を利用しているため、APIキーは唯一無二です。 

しかし、常に問題なく運用されるとは限りません。APIキーは盗難のリスクが高く、脆弱なネットワーク通信によって漏洩し、重大な脅威をもたらす可能性があります。 

4. 認証なし

最後に、詳細な認証プロセスを経ずにAPIへアクセスする方法も存在します。開発者は対象のURLにリクエストを送り、適切な応答を受け取るだけです。主に内部APIに適用されますが、有効性は高くないため推奨はいたしません。 

REST API認証：簡単なコツ

初期のAPIのひとつであるREST APIは広く利用されています。RESTフレームワークを用いると、開発が容易で拡張性の高いWeb APIが次々と生み出されます。RESTを用いる際は、トークンによる検証、SSLの利用、エラーメッセージの拡散防止、パラメータの検証といったAPI認証のベストプラクティスを忘れないようにしてください。 

製品として提供されるAPIは、プライベートキーやクライアントID、またはアクセスレベル・有効期限・呼び出し回数を管理するサブスクリプション方式で守るのが望ましいです。必要な時にプライベートキーが利用できるようにしておくことが重要です。  

WebベースのREST APIでは、TLSの採用は必須です。これにより、未認証のリソースに情報が提供されることを防ぎ、転送中のデータを暗号化し、不正アクセスから守ります。  

REST APIはSSOまたはシングルサインオンに最適化するのが望ましいです。この方法では、API提供者が第三者の認証サービスを利用し、利用者とAPI提供者双方にトークンを発行します。ログイン時には双方のトークンが照合され、一致した場合にのみ認証が成立します。 

すべてのAPIエンドポイントで同一のアクセス戦略を用いるのは避け、用途に応じてアクセス方法を多様化してください。APIキーと共に権限を単純な文字列リスト（例えば『write』や『read』）として保存することで、容易に実現できます。 

これらを採用することで、REST APIは不正アクセスや不適切な利用から十分に守られます。 

正しいAPI認証手法の選び方のコツ

API認証手法には多様な種類があり、どれを採用すべきか迷いが生じることがあります。しかし、適切な選択をするためのポイントを以下にまとめましたので、参考にしてください。 

• 期待するセキュリティレベルを把握する

まず、APIセキュリティに対する期待値を整理してください。どの程度の堅牢性を求めるのか、例えば：

クライアント側のみを守るのか、サーバ側も含むのか

導入の容易さを求めるのか

拡張性も重視するのか

これらを整理し、各手法を比較のうえ、要件に最も合致するものを選んでください。例えば、アプリ開発者と提供者の両面でAPI認証を実装する必要がある場合は、APIキーの利用が適しています。  

拡張性を重視する場合は、OAuth認証を選択してください。導入以来、継続的に進化し、時代に沿ったセキュリティ対策を提供しています。現在はバージョン2.0が主流で、その優れた拡張性が評価されています。  

OAuthを採用すればバージョン間の移行はスムーズですが、実装や運用は容易ではなく、多方面での手間がかかる点も考慮する必要があります。 

• シンプルなものから始める

各手法には複雑さが異なるため、初心者はまずシンプルな方法から始め、認証プロセスの有効性を実感してから、より複雑で効果的な手法に移行してください。最初から複雑な方法を採用すると、早い段階で挫折する可能性があります。 

• 既存の認証基盤を確認する

すでに認証戦略がある場合は、その内容を十分に検討し、既存の仕組みに合致する解決策が見つかったときにのみ拡張してください。既存と将来の認証手法が調和することが重要です。 

例えば、HTTPベーシック認証とOAuth 2.0を組み合わせる際、同一のHTTPヘッダーを用いるとAPIがOAuthのみを参照してしまう可能性があります。異なる認証要素を用いることで、互換性の問題を大幅に解決できるため、統合前に十分な検討が必要です。 

‍

まとめ

強力なAPIを提供する準備が整っていても、適切なセキュリティ対策がなければ市場で評価を得ることは難しく、これまでのAPI開発努力が無に帰す恐れがあります。そのリスクを取る覚悟はあるでしょうか？ 

そうでない場合は、API認証の意味と実践方法を理解することから始めてください。上記の要点は以下の通りです。

• API認可ではない
• どのAPIにも必ず実装すべきで、例外は認められない
• 複数の手法が存在する
• 各手法には利点と欠点がある
• 導入は期待に応じて判断される
• 最適な利用者認証方法を十分検討することで、より良い判断が可能になる

一見複雑に感じられるかもしれませんが、API提供者または開発者として、APIが過度に露出して問題となるのを防ぐためには整理することが重要です。 

単独でも、または他の手法と組み合わせても、API認証は有効な方法です。今日から導入し、確固たるAPIセキュリティを実現してください。セキュリティが確保されたAPIこそが、これからの主役となります。