シンプルで安全PHP APIデザイン
私は、可動部分ができるだけ少ない安全なRESTful API Webサービスを設計しようとしています。いくつか質問があります。デザインが安全であることを確認したいと思います。
セキュリティのデータ転送レベルについては、SSL/TLSを使用して、傍受、MITM、リプレイ攻撃などを防止します。
あとはアクセス制御です。
私はOAuthと戦いたいと思っていません。その理由は、サードパーティに依存したくなく、ローカルサーバーを「オーセンティケーター」として設定する（または、OAuthと呼ぶ）ことは不可能です）。
だから私はランダムなトークンに依存するつもりでした。 CSPRNGライブラリ（PHPの$token = random_bytes(32)など）を使用して、各ユーザー名/パスワードに$token、パスワード保存機能（PBKDF2やbcryptなど）を使用してDBに保存します。トークンは、SSL/TLSを介してユーザーが取得することもできます。
次に、各リクエストで、ユーザーはトークンとJSONデータを送信します。それらが渡すトークンがDBに存在する場合、API呼び出しが処理されます。
これは私にかなりの数の質問を残します：
- トークンは一貫性を保つことができますか（失効または手動更新を除く）、またはトークンrequireを頻繁に「更新」する必要がありますか？もしそうなら、それを処理するための実行可能な方法は何ですか？ユーザーにWebページへのログインを強制して新しいトークンにアクセスさせると、APIの目的が損なわれるようです。 これ は、せいぜい論争の的であることを示しているようです。
- トークンをHTTPヘッダーに入れることの利点は何ですか（例：
Authorization: Token SOMERANDOMVALUE）と比較して、JSONリクエストの本文に詰め込むだけですか？どちらにしても、認証が成功しない限り、リクエストに対して何もしません。とにかくヘッダーに入れるつもりでしたが、気になりました。
また、誰かが安全なAPIの構築についてもっと学ぶための信頼できるソースを持っているなら、私はそれらを本当に読みたいと思います。
トークンは一貫性を保つことができますか（失効または手動更新を除く）、またはトークンを頻繁に「更新」する必要がありますか？もしそうなら、それを処理するための実行可能な方法は何ですか？
OAuthを実装したくない場合でも、 トークンの処理がOAuth（Paragraph 1.5および1.5 。更新トークンを使用すると、ベアラートークンが危険にさらされた場合に、ユーザーに資格情報を繰り返し提供するよう要求するのを避けながら、露出のウィンドウを短縮できます。
トークンをHTTPヘッダー（Authorization：Token SOMERANDOMVALUEなど）に入れることの利点は、JSONリクエストの本文にトークンを詰め込むことだけです。
私の知る限り、このヘッダーフィールドはこの目的のために意図されているので行われます。実際には、ユースケースに大きく依存します。 Authorizationヘッダーが一部のブラウザーによって自動的に送信されるリスクがあるため、CSRF脆弱性が導入される可能性があるため、CSRFトークンを実装したくない場合は、この方法で送信することは望ましくない場合があります。そのため、本文またはカスタムヘッダーフィールドに認証情報を追加しても問題ありません。
安全なAPI設計のヒントについては、 OWASPによるRESTセキュリティのチートシート を参照してください。実際、サイト全体が興味深いものです。これは、情報セキュリティについて理解を深めるための非常に良い出発点です。