OAuth 2.0でのクライアントの責任の理解

Question

私は自分自身のRESTfulアプリケーションでOAuth 2.0の内部動作を学んできましたが、Javascriptクライアントがそのプロセスをどのように処理しているかについては説明できません。

この時点で、クライアント（Angular 2 SPA）にユーザー名とパスワード（Django Oauth Toolkitと一緒にDjango Rest Frameworkを実行している）を要求します。クライアントはサーバーへのAJAXポスト（特に/ o/token）を作成し、リソース所有者のパスワード認証情報フローを使用して認証され、トークンによる応答を受け取ります。

今、私がこの時点までにすべてを正しく行っているとすれば、その時点からトークンを適切に処理する方法は不明です。

この時点で、私はAngularアプリケーションにトークンを変数に保存させ、APIに行われた呼び出しに（トークンと共に）権限ヘッダーを添付します。これは、正しいパーミッションを付与する限りでは機能しますが、ヘッダーの永続性を維持する方法を理解するのは難しいです（したがって、ユーザーが別のページに移動した場合でも、トークンは呼び出し可能です）。最初はクッキーに保存しましたが、私はセキュリティに懸念があります。

まず、これを正しく理解していますか？ここでどのようなセキュリティ上の問題を考慮する必要がありますか？もちろん、クライアントにトークンを保存するにはどうしたらいいですか？

Answer 1

はい、アクセストークンは永続的である必要があるため、ユーザーセッションデータとして保存する必要があります。たとえば、ユーザーがサイトを離れて再び開くと、自分がログインしていると見なされることになります。

セッションをサーバー側にすると、ユーザーセッションにセッションIDのみが格納され、すべてのユーザーデータが格納されます。あなたのデータベース。ユーザーは彼のアクセストークンを必要とせず、アプリケーションだけがアクセストークンを必要としません。 Djangoは非常に単純に見えるため、サーバー側のセッションを実施するための

Instructions：

データベースでバックアップされたセッションを使用したい場合は、あなたのINSTALLED_APPS設定に'django.contrib.sessions'を追加する必要があります。

インストールを構成したら、manage.py migrateを実行して、セッションデータを格納する単一のデータベーステーブルをインストールします。