Encryption)と呼ばれる別のもの)送信者は秘密鍵で署名(JWS)し、受信者は公開鍵でその署名を検証することで、情報が信頼できることを確認する署名により、情報の内容は公開されているが、その真正性は保証されるJWTは、IDプロバイダーによるシングルサインオン機能で広く利用されている。IDフェデレーションでは、IDプロバイダーが認証したJWTを他サイトが検証し受け入れることで、ユーザーが複数のサービスを同じ認証情報で利用できるようになる。このときのJWTは「IDトークン」とも呼ばれる。送信側の行うこと情報(クレーム)をJSON形式で作成する。作成した情報に対して、秘密鍵や公開鍵/秘密鍵ペアを使ってデジタル署名を行う。署名されたJSONデータ(JWT)を受信側に送信する。受信側の行うこと送信側から受け取ったJWTを受け取る。JWTに含まれるデジタル署名を検証するために、公開鍵を使用する(秘密鍵で署名された場合)。署名が有効であれば、JWTの中の情報(クレーム)が正しいと認識し、使用する。署名が無効であれば、情報が信頼できないと判断し、無視またはエラー処理を行う。認証の流れユーザーがログイン画面にアクセスアプリケーションのログイン画面にユーザーがアクセスログイン情報の送信ユーザーはユーザーIDとパスワードを入力し、サーバーに送信JWTの生成サーバーはログイン情報を検証し、正しい場合にJWTを生成。このJWTにはユーザーの識別情報や有効期限などが含まれる。再アクセス時のJWTの使用ユーザーが再度アプリケーションにアクセスする際、ブラウザは保存されたJWTを自動的にサーバーに送信JWTの検証サーバーは送られてきたJWTを検証し、有効であればユーザーを認証する。JWTが無効である場合は、ログインが必要リフレッシュトークンの使用JWTの有効期限が切れていた場合、リフレッシュトークンがあればそれを使って新しいJWTを取得することができる。リフレッシュトークンは、通常、JWTとは別に管理され、より長い有効期限を持っている。JWTの更新または再ログインリフレッシュトークンが無効であるか、存在しない場合は、ユーザーは再度ログイン情報を入力して新しいJWTを取得する必要がある。リフレッシュトークンリフレッシュトークンは、新しいアクセストークン(JWT)を取得するために使用されるため、これが漏洩すると攻撃者がユーザーの認証情報を不正に利用する可能性があり、リフレッシュトークンを保護するためにも、以下のセキュリティ属性を設定することが推奨される。HttpOnly属性この属性を設定することで、リフレッシュトークンがクライアントサイドのスクリプトによってアクセスされることを防ぐ。これにより、XSS攻撃によるトークンの盗難を防ぐことができる。Secure属性この属性を設定することで、リフレッシュトークンがHTTPSを通じてのみ送信されるようになる。これにより、中間者攻撃(MITM)によるトークンの傍受を防ぐことができる。設定することで、リフレッシュトークンがクロスサイトリクエストとともに送信されることを制限できる。これにより、CSRF攻撃を防ぐことができる。この仕組みを使うメリットアプリケーション側でユーザーの認証情報を管理する必要がなくなるデータベースへのアクセスが不要になるため、認証処理が高速化JWTをリクエストごとに送信し検証することで、ユーザーを安全に識別でき、セッションを使ってユーザー情報を保持する必要がないIDプロバイダーを利用することで、ユーザーは異なるサービス間でのログインの手間を省くことができ、サービスプロバイダーはIDプロバイダーの認証基盤を利用することで、セキュリティの向上とユーザー体験の改善を図ることができる。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。