JWTを理解する
Web API における認証/認可のフローに OAuth 2.0 の Authorization Code Grant を採用したとして、その際に発行されるアクセストークンの形式を JWT にしたと仮定。
アクセストークンの形式に JWT を採用した場合のメリットとして、リクエストごとに Authorization Server へアクセストークンを検証依頼する必要がなくなる。デメリットは、トークンを即座に失効できないため必然的にアクセストークンの有効期限を短くせざるを得ない。そのためリフレッシュトークンを用いたアクセストークンの更新が頻繁に発生する。ユーザの UX 的にはクライアント側で工夫すればいちいちログインを促されるといったことはなさそう。
JWT のペイロードに含めるデータ例
ユーザID
セッションID
JWT にはセッションIDだけ内包して、以降は従来のセッション管理とする場合
セッションデータそのもの
セッションストレージが不要となる
このケースの場合にいろいろ考慮する必要がある
その他
CSRF対策になる
JWTはAuthorizationヘッダを介してサーバに渡す
Cookieに保存してたら対策にならない
同様にクロスドメインも許可してはならない
Ajaxでヘッダを変更できるため
参考
なお、 JWT にセッションデータそのものではなく、セッション ID を (も) 格納する場合はここでは問題としません。また、 JWT そのものについても問題とはしません。あくまでセッションデータそのもののみを JWT に含むことでステートレスなセッション機構を実現する場合について考えます。