APIトークンとは
私は、モバイルアプリケーション（iOSとAndroid）およびAPI（PHP）のユーザー認証を処理する最良の方法を探しています。
私が研究したことから、オプションは次のとおりです。
HTTPS経由の基本認証-リクエストごとにユーザーのユーザー名/パスワードを確認します。
Sessions-各リクエストでセッションIDを送信します。サーバーは状態を維持します。したがって、アプリはユーザー名/パスワードを送信し、私のウェブサイトと同じように、以降のリクエストでログインしているユーザーのサーバーチェックを行います。
APIトークン-モバイルアプリはユーザー名/パスワードを送信し、トークンを受信して、これを後続のリクエストに追加します。トークンはDBに保存され、各リクエストでチェックされます。
APIトークンの説明は、セッションIDをDBに保存しているため、セッションと同じように見えるため、間違っていると思います。
- APIトークンの説明を修正できますか。それらは何のため？セッションIDとはどう違うのですか？
- APIトークンの利点は何ですか？
- oAuth（使用を簡素化する場合）は、単に「APIトークン」を作成するためのプロトコルですか？
私は専門家ではありませんが、私が手に入れた数セントを差し上げます。
1）APIトークンは少し一般的な用語です。通常、APIトークンは、サービスへのアクセスを要求するアプリケーションの一意の識別子です。サービスは、サービスのリクエスト時に使用するアプリケーションのAPIトークンを生成します。その後、認証のために、提供されたトークンを保存したトークンと照合できます。
セッションIDを使用できますが、その目的はAPIトークンとは異なります。セッションIDは認証の形式ではなく、承認の結果です。通常、ユーザー（リソースなど）の使用がユーザーに許可されると、セッションが確立されます。したがって、ユーザーがリソースへのアクセスを許可されると、セッションIDが作成されます。 APIトークンは、ユーザー名/パスワードに類似した認証形式です。
2）APIトークンは、安全ではないHTTPを介してユーザー名とパスワードの組み合わせを送信する代わりになります。ただし、誰かがAPIトークンを代わりに使用する可能性があるという問題は依然として存在します。
3）ある意味、はい。これは、APIトークンを「新鮮」に保つためのメソッドです。同じAPIトークンを渡す代わりに、サービスを使用するときにアクセストークンを要求します。 OAuth 2.0ステップは次のとおりです。
a）何らかの資格情報でサービスに送信されたリクエスト
b）成功した応答はコードを返します
c）サービスに関する別のリクエストがコードで行われます
d）成功した応答は、それから終了まで各API要求に署名するためのアクセストークンを返します。
大きなサービスプロバイダーの多くはOAuth 2.0を使用しています。これは完全なソリューションではありませんが、現時点で最も安全で広く普及しているAPIセキュリティメソッドです。