web-dev-qa-db-ja.com

Django：DRFトークンベースの認証VS JSONWebトークン

私は、ユーザーが主にAndroid、iOSデバイス、およびデスクトップからアプリにアクセスする実際のアプリケーションを構築しています。

私の初歩的な調査から、トークンベースの認証メカニズムは、セッションベースの認証と比較して、クライアントサーバーモデルの方が優れていてエレガントであることがわかりました。

Djangoで、これを行うための2つの一般的な方法を見つけました-

  1. http://www.Django-rest-framework.org/api-guide/authentication/#tokenauthentication
  2. http://getblimp.github.io/Django-rest-framework-jwt/

私が理解したところによると、オプション2]は1]の拡張ですが、トークンがJSON（シリアル化）の形式である点が異なります。オプション1]と2]の間に他にどのような違いがあるのか​​、そしてどちらかを選択することの長所/短所を理解したいと思います。

jsondjangorestdjango-rest-frameworktastypie
24
anon

どちらも、ほとんど違いはありませんが、同様のタスクを実行します。

トークン

DRFの組み込みトークン認証

  1. すべてのセッションに1つのトークン
  2. トークンにタイムスタンプはありません

DRF JWTトークン認証

  1. セッションごとに1つのトークン
  2. 各トークンの有効期限タイムスタンプ

データベースアクセス

DRFの組み込みトークン認証

  1. トークンに関連付けられたユーザーをフェッチするためのデータベースアクセス
  2. ユーザーのステータスを確認する
  3. ユーザーを認証します

DRF JWTトークン認証

  1. トークンのデコード（ペイロードの取得）
  2. トークンのタイムスタンプの確認（有効期限）
  3. ペイロード内のIDに関連付けられたユーザーをフェッチするためのデータベースアクセス
  4. ユーザーのステータスを確認する
  5. ユーザーを認証します

長所

DRFの組み込みトークン認証

  1. データベース内のトークンを置き換えることで強制ログアウトを許可します（例：パスワードの変更）

DRF JWTトークン認証

  1. 有効期限のあるトークン
  2. トークンが有効でない限り、データベースはヒットしません

短所

DRFの組み込みトークン認証

  1. すべてのリクエストでデータベースがヒット
  2. すべてのセッションに単一のトークン

DRF JWTトークン認証

  1. データベースで追跡せずにトークンを呼び出すことはできません
  2. トークンが発行されると、トークンを持っている人は誰でもリクエストを行うことができます
  3. 仕様は解釈の余地があり、更新方法に関するコンセンサスはありません
38
un33k