web-dev-qa-db-ja.com

APIの設計：HTTP基本認証とAPIトークン

現在、Webアプリケーション用のパブリックWeb APIの前に認証システムを作成しています。各ユーザーアカウントにAPIキーがあり、各リクエストを認証する必要がある場合、2つの選択肢があります。

  1. HTTP基本認証を使用して、 GitHubと同様 。

    リクエストはURLに送信する必要があります

    http://api.example.com/resource/id
with basic authentication
username: token
password: the api key

  2. クエリ文字列パラメーターとしてAPIトークンを渡します。

    リクエストはURLに送信する必要があります

    http://api.example.com/resource/id?token=api_key

URI内でトークンを渡す3番目のオプションもありますが、私は正直にそのソリューションが好きではありません。

どのソリューションを採用しますか？その理由は何ですか？

apiauthenticationarchitecturebasic-authentication
51
Simone Carletti

HTTP Basic Authは大丈夫だと思うが、本当にシンプルなニーズのためだけだ。

私見の完全な（そして最終的な）ソリューションは、OAuthプロバイダーを実装することです。複雑ではなく、シンプルなプロトコルであり、柔軟性が非常に高くなっています。さらに、多くの大手企業がそれを実装しており、多くの多くのライブラリからサポートされているため、現在の傾向のようです。

12
Diego Giorgini

最善策は、URLパラメーターとしてではなく、ヘッダーでAPIキー（たとえば、「Authorization：Token MY_API_KEY」）を使用することです。

HTTP Basic Authの利点：

  • ユーザーのアカウントパスワードに影響を与えずにトークンを簡単に期限切れまたは再生成できるため、より便利です。
  • 侵害された場合、脆弱性はユーザーのマスターアカウントではなくAPIに限定されます
  • アカウントごとに複数のキーを持つことができます（たとえば、ユーザーは「テスト」キーと「本番」キーを並べて持つことができます）。

RLのAPIキーの利点：

  • 資格情報が埋め込まれたURLをユーザーが誤って共有することを防ぐことで、セキュリティの追加手段を提供します。 （また、URLはサーバーログのようなもので終わる可能性があります）
34
Yarin

APIでユーザー/リクエストを認証する方法について何度も考える必要があり、より多くのソリューションを比較した後、 Amazonのソリューション を使用することになりました。このソリューションは、基本認証と単純なトークンの受け渡しがプレーンテキストデータを送信するため、「中間者」問題を防ぐ署名に基づいています。はい、sslを追加できますが、これによりシステムが複雑になります...

17
dlondero

トークンソリューションの使用を希望します。自分のユーザー名とパスワードを持つ実際のユーザーがいない場合は、意図したとおりに基本認証構造を使用していないように感じます。それは必ずしも間違っているわけではありませんが、IMOほどきれいではありません。また、カスタムヘッダーを使用する必要がなくなり、両側での実装がより簡単に、よりクリーンになります。次の質問は、2要素認証を使用する必要があるのか​​、セッションをまったく管理する必要があるのか​​ということです。

0
Christopher Martin