トップQs
タイムライン
チャット
視点
JSON Web Token
Web アプリケーション環境における当事者間のクレームの受け渡しのための JSON ベースのオープンスタンダード (RFC 7519) ウィキペディアから
Remove ads
JSON Web Token(ジェイソン・ウェブ・トークン)は、JSONデータに署名や暗号化を施す方法を定めたオープン標準 (RFC 7519) である。略称はJWT。
概要
JWTでは、トークン内に任意の情報(クレーム)を保持することが可能であり、例えばサーバはクライアントに対して「管理者としてログイン済」という情報を含んだトークンを生成することができる。クライアントはそのトークンを、自身が管理者としてログイン済であることの証明に使用することができる。トークンは当事者の一方(通常はサーバ)または両方(もう一方は公開鍵を提供する)の秘密鍵により署名されており、発行されたトークンが正規のものか確認することができる。
JWTのトークンはコンパクトな設計となっており[1]、またURLセーフである[2]。サーバー側でセッションを保持せずにユーザーの認証・認可を管理するのに適しているため、OAuthのアクセストークンやOIDCの認証トークンとして使われている[3]。トークンには一般的にアイデンティティプロバイダやサービスプロバイダが認証したユーザー識別情報が格納される他、各々のサービスで必要な情報も格納される[4][5]。
JWTは他のJSONベースのオープン標準であるJSON Web Signature (JWS, RFC 7515) とJSON Web Encryption (JWE, RFC 7516) に拠って立っている[6][7][8]。
Remove ads
構造
JWTのトークンは以下の3つの要素から構成される。
これら3つの要素は、Base64URLでエンコードされた上で、ピリオドにより結合される。以下にコード例を示す。
const token = base64urlEncoding(header) + '.' + base64urlEncoding(payload) + '.' + base64urlEncoding(signature)
上記データは、秘密鍵が"secretkey"の場合、以下のようなトークンとなる。
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
Remove ads
使用
ユーザーがサーバにログインを行う場合、従来のセッションによる認証ではCookieにてセッションIDが返されるが、JWTにおいてはトークンが返され、それをローカルに保存して利用する(主にlocal storageやsession storageが用いられる。セッションIDのようにCookieを用いる場合もある)。
ユーザーが認証が必要な機能やリソースにアクセスする際、クライアントはトークンを何らかの手段、主としてAuthorization
ヘッダーでBearer
スキーマを用いてサーバに送信する。この場合、Authorization
ヘッダーは以下のような形式となる。
Authorization: Bearer eyJhbGci...(中略)...yu5CSpyHI
JWTは、サーバ上に認証状態を保持しないステートレスな認証方式である。サーバはAuthorization
ヘッダーで渡されたトークンが正しいかだけを検証し、アクセスを許可する。JWTにおいては、認証に必要な情報は全てトークン内に格納されており、データベースへの問い合わせを削減することができる。
標準フィールド
RFC 7519においては、含める以下のような利用可能な標準フィールド(クレーム)が定義されている。
ヘッダーのフィールド
ペイロードのフィールド
Remove ads
セキュリティ対策
JWTがステートレスであり、また認証・認可のトークンとして使用されることから、窃取されたときの影響が大きい。トークンを送信する際は必ずHTTPS (HTTP over SSL/TLS) を使用し、通信経路全体を暗号化する必要がある。また、JWTトークンが漏洩した場合のリスクを考慮し、有効期限をできるだけ短く設定しておく[14]。
JWTをCookieに保存する際は、最低限のクロスサイトスクリプティング (XSS)対策として、HttpOnlyフラグを設定し、JavaScriptからのアクセスを禁止する対策が必要である。また、クロスサイトリクエストフォージェリ (CSRF)対策として、SameSite属性をStrictまたはLaxに設定し、外部サイトからのリクエストで自動的にCookieが送信されることを制限する必要がある[14]。
脆弱性と批判
JWTはステートレスであることから、JWT単体ではトークンを無効にすることが出来ない。従来のセッション同様、サーバに状態を保持すれば可能だが、その場合ステートレスの利点は失われる[15]。
署名の脆弱性
セキュリティコンサルタントのTim McLeanは、複数のJWTライブラリがalg
クレームに署名無し (none
) 等を指定した不正なトークンを処理してしまう脆弱性を報告した。これらの脆弱性は修正されたが、McLeanは同様の問題を防ぐためalg
クレーム自体を廃止すべきだと主張している[11]。
署名アルゴリズムの脆弱性については、以下のような方法で対策が可能である[16]。
- JWTヘッダーだけを見て検証しない。
- アルゴリズムについて知る。
- 適切なキーサイズを用いる。
関連項目
出典
外部リンク
Wikiwand - on
Seamless Wikipedia browsing. On steroids.
Remove ads