API認証とAPI認可の違い
英語によるオリジナルはこちらでご覧いただけます。
このブログ記事にたどり着いた方は、APIセキュリティに関心があるのではないでしょうか。セキュリティはAPIの重要なテーマの1つです。API攻撃が増加傾向にあるなかで、自社のデータが不正アクセスの被害に遭うのは避けなくてはなりません。APIセキュリティで重要な意味を持つのが、API認証とAPI認可の導入です。この2つのアクセス制御手法はAPIセキュリティの土台となります。
自社のAPIのアクセス制御に不安がある場合には、早急に確認と軌道修正を図りましょう。この記事では、認証と認可の違い、主な認証手法、最適な認証手法の選び方について詳しく説明していきます。
認証と認可の違い
API認証とAPI認可は別物ですが、混同しがちです。どちらも適切な人に適切なデータへのアクセスを認める目的で使う手段だということはご存じかと思います。しかし、具体的な違いは何でしょうか。そして、なぜ両方とも必要なのでしょうか。
例え話として、APIを図書館になぞらえてみましょう。そして、APIが提供する機密データは希少な初版本に相当するとします。この場合、API認証とは、図書館に本を借りに来た1人ひとりの身元を公的な身分証明書でチェックして、間違いなく本人であることを確認するプロセスにあたります。またAPI認可とは、本人確認を通過した人の図書館利用者票をチェックして、希少本コーナーへの立ち入りが認められた人かどうかを確認するプロセスにあたります。
認証と認可は連携して、APIのセキュリティを共に守ります。図書館の例で言うと、本人であることが証明された利用者だからといって、希少本コーナーに立ち入る権限があるとは限りません。つまり、たとえ認証に合格しても、認可で不合格になって本を借りられないケースはあり得ます。APIも同じです。認証と認可を組み合わせることで、適切な人が適切なデータにアクセスできる環境を構築できます。
API認証とは
API認証では、ユーザーが間違いなく本人であることを検証します。後でいくつか説明しますが、API認証にはさまざまな手法があります。いずれも、APIに接続しようとしているユーザー（あるいはクライアントアプリケーション）のIDを検証するために使用する手法である点は同じです。
API認可とは
ユーザーのIDの検証が済んだら、今度はそのユーザーがどのデータへのアクセスを認められているかを確認できます。そのプロセスが認可です。特定のデータを表示する権限、あるいは編集する権限を持っていることを、認可のプロセスで確認します。
API認証のメリット
API認証はデータのセキュリティを確保するために不可欠です。ユーザーが間違いなく本人だと検証することによって、次のようなメリットが得られます。
不正アクセスを阻止：ユーザーのIDを証明することで、正規ユーザーになりすました攻撃者が、機密データに不正にアクセスするのを阻止できます。
データ整合性を確保：不正アクセスに成功した攻撃者は、機密データを参照できるだけでなく、データセット全体の改ざんや削除も可能です。また、ユーザー認証を行っていない環境では、たとえ悪意がなかったとしても、ユーザーの行為でデータ整合性が誤って損なわれる恐れがあります。
アクセス制御に対応：APIユーザーを認証する場合に、データへのアクセス権を個々のユーザー単位で設定する必要はありません。アクセス制御ポリシーを利用して、どのユーザーグループがどのリソースにアクセスできるかを定めたルールを、ユーザーグループ単位で適用できます。
監査が容易に：API認証を導入していると、どのユーザーがいつデータにアクセスしたかを非常に簡単に特定できます。問題が発生した場合のデバッグや、不審な行動の追跡、セキュリティ標準への準拠（必要な場合）に監査ログを活用できます。
シンプルな連携：APIと連携可能な製品の多くは認証が必要です。こうした製品がAPIに接続する時点で認証情報を取得しておけば、その後は追加情報の受け渡しなしでスムーズに連携できます。
主なAPI認証手法
このように不可欠な存在であるAPI認証ですが、導入は何から始めればよいのでしょうか。
最初のステップは認証手法の選択です。認証手法にはさまざまな種類があり、どれが適切かはケースバイケースです。手法ごとの違いを理解しておくことが、自社に合った最適な手法の選択につながります。ここからは、4種類の主なAPI認証手法を見ていきましょう。多数の企業でAPIセキュリティに広く導入されている手法です。
ベーシック認証
HTTPのベーシック認証は最もシンプルなAPI認証手法です。この手法では、すべてのAPIコールのリクエストにユーザー名とパスワードを付加します。
ベーシック認証のメリット
- ベーシック認証は軽量で、実装が簡単です。Cookieやログインページを必要とせず、HTTPヘッダーにそのまま組み込めます。
ベーシック認証のデメリット
- ベーシック認証は、セキュリティ侵害に対して脆弱です。簡単に実装できるものの、安全性は抜群とは言えません。ユーザー名とパスワードはBase64でエンコードしますが、暗号化はされないため、第三者が簡単に復号化できます。この第三者は、正規のユーザー名とパスワードを使ってAPIにアクセスできることになります。加えて、ベーシック認証はパスワードのブルートフォース攻撃を防ぐ手立てがなく、その点も不正アクセスの原因となります。さらに、簡単に推測できる弱いパスワードを設定するユーザーが出てくることは言うまでもありません。
- ユーザーがパスワードを簡単にリセットできません。ベーシック認証では、ユーザーがパスワードを忘れたときに、簡単にリセットする手段がありません。企業の管理者にとって、厄介な問題となることでしょう。
トークン認証
トークン認証はBearer認証の名でも知られています。この認証方式を使用する場合、「Authorization: Bearer <token>」という形式のヘッダーを使って、ユーザーのIDや権限を示す文字列をトークンとして渡します。Bearer（所持者・持参者）という名前が示すように、トークンを所持しているユーザーは、APIへの適切なアクセス権が得られます。
トークン認証のメリット
- ベーシック認証よりも安全性に長けています。トークンは暗号化されているため、ベーシック認証のユーザー名とパスワードのようなデコードや流出は起きません。トークンには有効期限を設定できるため、永久にアクセス可能な権限を付与せずに済みます。
- 認可にも利用できます。認証と認可の両方に対応するBearerトークンによって、一連のプロセスがシンプルになります。
トークン認証のデメリット
- トークンの有効期間は、ユーザー名とパスワードよりも短くなっています。トークンに有効期限があることは、セキュリティという面ではメリットです。しかし、古いトークンの期限が切れたという理由で、新しいトークンの生成を頻繁に求められるのは、ユーザーにとってフラストレーションの原因にもなります。
- トークンを盗んだ攻撃者は、保護されているデータにアクセスできます。トークン認証はベーシック認証よりもセキュアではあるものの、100%安全なわけではありません。攻撃者がトークンを盗み、その有効期限が切れるまでデータにアクセスする可能性があります。
- ベーシック認証よりも実装が複雑です。ごく基本的なベーシック認証に比べると、トークン認証の実装には多くの作業が必要です。
OAuth認証
OAuthは、トークン認証の一種を使用するオープンな認可フレームワークですが、サービスプロバイダへのログインに、別のサービスプロバイダの認証情報を使用します。
OAuth認証のメリット
- 使いやすいシングルサインオン（SSO）をユーザーに提供できます。ユーザーは、サービスプロバイダにログインするときに使う認証情報を、使いやすいGUIで入力して、トークンを生成できます。こうして認証したIDは、他のサービスプロバイダでも使用できます。例えば、自社のアプリケーションにGoogleのアカウントでログインできるようにする機能を、OAuthを利用して提供できます。
- また、安全性にも優れています。Bearerトークンと同様に、OAuthはベーシック認証に比べてセキュアなのです。
- 認可にも利用できます。Bearerトークンと同様に、OAuthはユーザーの認証と認可の両方に対応します。
- きわめて広く利用されていて安全性に優れています。多くの企業がAPIにOAuthを利用しているのは、そのセキュリティに対する信頼の表れです（理由はトークン認証のところで述べたとおりです）。また、広く利用されているため、実装に役立つ参考資料や情報も豊富です。
OAuth認証のデメリット
- トークンを盗んだ攻撃者は、保護されているデータにアクセスできます。前述のトークン認証と同様に、OAuthのトークンも盗まれる恐れがあり、データへの一時的なアクセスに利用される可能性があります。
- ベーシック認証よりも実装が複雑です。Bearerトークンと同様に、OAuthの実装はベーシック認証に比べて多くの作業が必要です。
APIキー認証
APIキーも、ベーシック認証に比べて非常に安全です。文字列を通じてアクセスを許可する仕組みですが、トークン認証とは重要な違いが1つあります。
トークン認証は、APIにアクセスしているのがどのユーザーなのかを証明しますが、リクエストを実行しているアプリケーションの情報は提供しません。APIキーはその逆で、リクエストを実行しているアプリケーションの情報を提供しますが、ユーザーごとの情報は提供しません。
APIキー認証のメリット
- APIキーを利用して、ユーザーはプログラムからAPIにスムーズにアクセスできます。APIキーはユーザー個人ではなくアプリケーションと紐づいているため、スクリプトに簡単に組み込んで、プログラムでAPIにアクセスできます。
- 認可にも利用できます。BearerトークンやOAuthと同様に、APIキーはAPIアクセスの認証と認可の両方に対応できます。
APIキー認証のデメリット
- ベーシック認証よりはセキュアですが、トークン認証やOAuthに比べると劣ります。なぜなら、複数のユーザーが同じAPIキーを使ってアクセスできるからです。APIキーはユーザー個人ではなく、リクエストを実行するアプリケーションと紐づいています。
- APIキーには有効期限がありません。攻撃者がAPIキーを手に入れた場合、トークンのような期限切れがない分、機密データにアクセスできる時間が長くなります。
メモ：APIキーはトークン認証やOAuthと併用できます。その場合、ここに挙げたデメリットはある程度緩和されます。
最適なAPI認証手法の選び方
最適なAPI認証手法を選ぶには、メリットとデメリットを比較検討し、自社のニーズについて考える必要があります。また、APIに接続してくるクライアントの種類や、それらがサポートする手法を考慮することも重要です。
認証なしで運用中のAPIに、最も短時間で手軽にセキュリティを実装したいのであれば、すばやく導入できる当座しのぎの策としてベーシック認証が適しているかもしれません。一方、機密のユーザーデータをデータベースに保管している企業であれば、OAuthやAPIキー認証など、もっとセキュアな手法を選ぶのがよいでしょう。
また、どのようなユーザー体験を提供したいのかという点も考える方がよいでしょう。テクノロジに精通したユーザーがプログラムからのアクセスを必要としている場合には、APIキーの方が受け入れられるかもしれません。一方、技術系ではない人向けに簡便なログイン機能を提供したいと考えているのであれば、使い慣れた信頼できるアプリケーションを通じたSSOを可能にするOAuthの方が受け入れられるかもしれません。
どの手法を採用する場合でも、この記事で説明したAPI認証と認可に関する知識は役立つことでしょう。認証と認可の両方を確実に導入して、データを危険から守りましょう。