こんにちはREST APIエンドポイントを使用してサーバー側と通信するモバイルネイティブアプリケーションを作成しています。以前にネイティブクライアントの開発経験がありますが、シンプルなトークン(ランダムに生成された文字列)がDBに保存されていますユーザー情報が格納されているのと同じテーブルです。つまり、ブラウザで使用されるセッションのようですが、Cookieの代わりに、各リクエストのヘッダーにトークンがあります。
最近、JWTトークンを取り除きました。プライベートなエンドポイントを保護するための素晴らしい方法のようです。パス+ログインを提供するモバイルクライアントからトークンをリクエストし、応答として生成されたトークンを取得できます。しかし、重要なことの1つは、このトークンがサーバーのどこにも保存されていないことです。サーバーは、秘密鍵のようにサーバーにプライベートである秘密のWordを使用してトークンを検証します。安全なエンドポイントの場合は問題ありませんが、たとえばFacebook、Amazon、Aliexpressなどのアプリがどのように機能するかなど、ユーザーセッションが必要な場合はどうすればよいですか、資格情報を提供せずにストアをナビゲートするだけでアプリを使用できますが、ユーザーが購入したくないときにログインする必要があります。その後、ユーザーセッションはしばらく保持されます。これは問題なくJWTトークンで実装できますが、ユーザーがログアウトする必要がある場合、この場合はどうしますか?トークンはサーバーのどこにも保存されていないので、このトークンを破棄して無効にする方法を教えてください。
トークンがデータベースに保存されている場合、APIはステートレスではありません。REST APIはそうである必要があります。したがって、一般に、ユーザーをステートレスAPIにログインさせておく方法はありません。よろしいですか?
私はJWTトークンを使用してこれを実装する方法をいくつか考えていますが、これもステートレスAPIではありません。
この場合の最善の方法は何かを提案し、間違っている場合は修正してください。ありがとう。
JWTトークンは、主にアサーションメカニズムとして設計されています。つまり、関連するユーザー情報を提供して、サーバーがユーザーに代わって操作を実行しているユーザーを「認識」できるようにします。 JWTは次のシナリオに最適です
セッションで使用しているようですが、同じように使用するのはベストではないと思います。
セッション管理にはOAuthの方が適切だと思います。これは、更新トークン(セッションの有効期限が切れた場合のセッション拡張)、セッション管理の概念に簡単にマップできるアクセストークン(セッションID)などの基本的な概念で設計されています。 OAuthの場合、認証方法(JWTなど)はサーバーが決定します。その後、セッション中にクライアントが必要とするのはアクセストークンだけです(セッションIDと同様)。発生している最大の問題は、アクセストークンと更新トークンをサーバーに保存して管理する必要があることです。アクセストークンをセッションIDに簡単にマッピングできる場合は、その必要性を取り除くことができると思います。しかし、すでにJWTの格納に取り組んでいることを考えると、これは問題にはなりません。
あなたはJWTの古典的な制限を見ています。セッション管理用には設計されていません。ただし、それらを いくつかの制限 で使用できます(ブラックリストを使用しない限り、ログアウトなし、アイドルタイムアウトなしなど...)
最終的には、ユースケースで許容できるものを決定する必要があります。詳細を見てみましょう。
facebook、Amazon、Aliexpressなどのアプリはどのように機能しますか、
彼らのセッション管理の正確な性質は私には不明です。彼らはステートフルなセッション管理またはその2つの組み合わせを使用して目的を達成していると思います。
しかし、ユーザーがログアウトする必要がある場合、この場合はどうしますか?
JWTを使用する場合は、トークンをブラックリストに登録する方法が必要です。これには、状態の保存が必要です。これは、あなたが説明したようにサーバー側の場合もあれば、この状態を保持するためだけの専用サービスをセットアップする場合もあります(これにより、APIがステートレスのままになりますが、複雑さが生じます)。
では、このトークンを無効にして無効にするにはどうすればよいですか?
JWTを破棄することはできません。署名キーを変更することで無効化することは可能ですが、[〜#〜] all [〜#〜]トークンが無効になるため、同じキー。
したがって、一般に、ユーザーをステートレスAPIにログインさせておく方法はありません。そうですか?
「ログイン済み」であることは、どこかに保存する必要がある状態です。サービスにアウトソーシングすると、APIがステートレスになり、ログインとログアウトをサポートできるようになります。
私はJWTトークンを使用してこれを実装する方法をいくつか考えていますが、これもステートレスAPIではありません。
- 期限切れのトークンのリストを作成する
これはJWTブラックリストと呼ばれ、あなたが説明した目的を果たします。
- JWTトークンをデータベースに格納しますが、この場合、自己記述型トークン(JWT)がデータベースに格納されている場合の目的は何でしょうか。JWTトークンの主な目的は、すべての情報をトークンとともに保持することです。
そのとおりです。これにより、自己記述機能がほとんど役に立たなくなります。
以上をまとめると、JWTのメリットが必要かどうかを判断する必要があります。もしそうなら、あなたはその欠点に耐えることができますか?私の意見では、ほとんどの場合、ステートフルセッションを優先する必要があります。
認証の選択肢に興味がある場合は、 web api authentication guide を確認してください。