JWT とマイクロサービス かとじゅん (@j5ik2o) 1 / 23

JWT とは JSON Web Token ( ジョット) ­ RFC7519 一連の要求を表すJSON オブジェクトとしての文字列。JWS またはJWS でコード化され、クレームは電子署名される か、暗号化される。 関連する仕様 JWS(JSON Web Sigature) ­ RFC7515 電子署名付きのメッセージ表現 JWE(JSON Web Encryption) ­ RFC7516 暗号化のメッセージ表現 JWK(JSON Web Key) ­ RFC7517 暗号鍵のJSON 表現 JWA(JSON Web Algorithm) ­ RFC7518 JWS,JWE などで扱われる暗号アルゴリズム JWT とマイクロサービス 2 / 23

JWT(JWS) の例 eyJjdHkiOiJKV1QiLCJ0eXAiOiJKV1QiL CJhbGciOiJSUzI1NiIsImtpZCI6ImlOUVh0dFR2RHZhcDVkSW pGQzA5ZHZadHFXaGQ2WmFRb2pKenVuUS1vV28ifQ.eyJh dWQiOiJodHRwczovL2FwaS5jaGF0d29yay5jb20iLCJzdWIi OiIzIiwiYWNjb3VudF9pZCI6IjMiLCJzY29wZSI6WyJhbGwiXS wiaXNzIjoiaHR0cHM6Ly9vYXV0aC5jaGF0d29yay5jb20iLC JleHAiOjE1MDExMzgwNDEsImlhdCI6MTUwMTEzNzE0MSw ianRpIjoiOTcwNDAwOWItNTdlNi00NDU5LTg5NzMtNjc3Zm M5YjA5MjgyIiwiY2xpZW50X2lkIjoiTHZvMFlOOTJnYTVrUCJ9. BIS8QvyTHz7KK_fnmvc0fa8NQDOWy7v8Ni0LvLyuROE5UEi 7l_HxDT8tHLTQLELIm3jOw4SiW94KPYwduRL467vJ2j2eNT -zTkCXtEN8pxbA0HtnBrtCcp0dRJEMnfBegzkoAe8BTB6gee 3rrXy6sQcLb19WBrrHNbjICFL0--SG3IvPanOzABqiNMqfScn asTtj7xtIaNpbxf8LDIH3EF150Iif4BqSczJr-XppBTBYuP32Ul BnRlQOXvXqymGijQXgqDOo3LLFY_k62OoPYAQ3UXkaum8 6Al-DJM6iC-043kBINbYLLPo0uwwsolmjRDG5zBzPC0GtcjXiLy4Gqg" JWT とマイクロサービス 3 / 23

// JOSE ヘッダ eyJjdHkiOiJKV1QiLCJ0eXAiOiJKV1QiL CJhbGciOiJSUzI1NiIsImtpZCI6ImlOUVh0dFR2RHZhcDVkSW pGQzA5ZHZadHFXaGQ2WmFRb2pKenVuUS1vV28ifQ . // JWS クレームセット eyJh dWQiOiJodHRwczovL2FwaS5jaGF0d29yay5jb20iLCJzdWIi OiIzIiwiYWNjb3VudF9pZCI6IjMiLCJzY29wZSI6WyJhbGwiXS wiaXNzIjoiaHR0cHM6Ly9vYXV0aC5jaGF0d29yay5jb20iLC JleHAiOjE1MDExMzgwNDEsImlhdCI6MTUwMTEzNzE0MSw ianRpIjoiOTcwNDAwOWItNTdlNi00NDU5LTg5NzMtNjc3Zm M5YjA5MjgyIiwiY2xpZW50X2lkIjoiTHZvMFlOOTJnYTVrUCJ9 . // JWS 署名 BIS8QvyTHz7KK_fnmvc0fa8NQDOWy7v8Ni0LvLyuROE5UEi 7l_HxDT8tHLTQLELIm3jOw4SiW94KPYwduRL467vJ2j2eNT -zTkCXtEN8pxbA0HtnBrtCcp0dRJEMnfBegzkoAe8BTB6gee 3rrXy6sQcLb19WBrrHNbjICFL0--SG3IvPanOzABqiNMqfScn asTtj7xtIaNpbxf8LDIH3EF150Iif4BqSczJr-XppBTBYuP32Ul BnRlQOXvXqymGijQXgqDOo3LLFY_k62OoPYAQ3UXkaum8 6Al-DJM6iC-043kBINbYLLPo0uwwsolmjRDG5zBzPC0GtcjXiLy4Gqg" JWT とマイクロサービス 4 / 23

JWS Compact Serialization BASE64URL(UTF8(JWS Protected Header)) || '.' || BASE64URL(JWS Claim Set) || '.' || BASE64URL(JWS Signature) JOSE ヘッダは署名されていないので、簡単にデコード可能 JWT とマイクロサービス 5 / 23

クレームセットの例 予約済みクレーム(iss, sub, aud, exp など) 独自のクレームもセットできる {"iss":"accounts.google.com", "at_hash":"HK6E_P6Dh8Y93mRNtsDB1Q", "email_verified":"true", "sub":"10769150350006150715113082367", "azp":"1234987819200.apps.googleusercontent.com", "email":"[email protected]", "aud":"1234987819200.apps.googleusercontent.com", "iat":1353601026, "exp":1353604926 } JWT とマイクロサービス 6 / 23

JWT に対する印象 やたら長い… 。仕様上も長さの上限が規定されていない ヘッダに格納することを考えると 7 ～8KB ぐらいが限界… 。 DB に格納したとき死ぬの？ JWT とマイクロサービス 7 / 23

JWT の用途 セッションストア どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ？ アクセストークン JWT 形式を採用したChatWork のアクセストークンについて 今日は、アクセストークンに適用したケースで話します。 JWT とマイクロサービス 8 / 23

その前に OAuth2 のフロー JWT とマイクロサービス 9 / 23

OAuth2 フローの概要 JWT とマイクロサービス 10 / 23

アクセストークン形式の種類 Artifact トークンにはメタデータを保持せずID のみ。メタデータはサーバ側のストレージに持つことが一般的 ex) 86277ab4fd9d111bd3225215d96d622c9ae6810d82 Assertion メタデータをすべて内包する形式。JWT はその代表格 JWT とマイクロサービス 11 / 23

Assertion 形式を選ぶ理由 1. サーバ側でメタデータを管理するストレージの運用コスト削減のため 2. マイクロサービスが増えた場合に、リソースサーバ単体で認証・認可の検証を実装しやすい JWT とマイクロサービス 12 / 23

Assertion 形式の制約 JWT とマイクロサービス 13 / 23

アクセストークンの失効ができない JWT などのAssertion 形式のトークンはサーバーに状態を持たないため、失効ができない。有効期限がつかないものは無限 の寿命を持ってしまう サーバ側のブラックリストを使うと即時失効可能になるが、失効に関してはArtifact と同じ特徴も持つことになる トークンが漏れた場合は以下の対応が必要 認可サーバでの当該認可の破棄 リソースサーバでの利用権限の一時停止 Artifact 形式であっても分散キャッシュから短い時間に消すことは難しい 有効期限が十分に短いJWT と、有効期限が長いリフレッシュトークンの組み合わせで使うとよい JWT とマイクロサービス 14 / 23

アクセストークンが偽造されていな いか、検証するために電子署名(JWS) の仕組みを利用します 電子署名用鍵ペアは永続化される が、アクセストークンは払い出すの み リソースサーバはHTTPS 経由で公開 鍵を入手し検証するだけ 署名用鍵ペアを管理する必要がある JWT とマイクロサービス 15 / 23

JWK( 公開鍵 ) の例 { "keys" : [ { "kty" : "RSA", "use" : "sig", "ops" : [ "sign", "verify" ], "alg" : "RS256", "kid" : "e7c1ab27-9b4c-4a85-a476-1274feb845ae", "x5c" : [ ], "n" : "g0BrrBcjPKX3yPxGGho1dTx...Bn1UbmPqXMkTRbw", "e" : "AQAB" }, // ... ] } JWT とマイクロサービス 16 / 23

アクセストークンの代わりにリフレッシュト ークンを永続化する JWT のように長い文字列をDB に保存する際、インデックス化に問題が生じることがある アクセストークンを永続化せずにオンメモリで保持し、文字列長が短いリフレッシュトークンを保存する アクセストークンを失ったとしても、リフレッシュトークンの期限内であれば、再度アクセストークンを取得できる JWT とマイクロサービス 17 / 23

Artifact ならトークンイントロスペクション OAuth 2.0 Token Introspection RFC7662 認可サーバを利用し、トークンを識別し、トークンに関するメタデータを返すため仕様 レスポンス形式は、クレームセットと同様(iss, aud, sub など) JWT とマイクロサービス 18 / 23

マイクロサービスに向いている方はどちらか Assertion 不変前提 各サービス単体で検証できる トークンはサーバで管理する必要がない Artifact 可変にできる 各サービスからトークン検証要求を受け付ける必要がある(SPoF にならないように) トークンのデータ量が多い場合、運用コストも比例する JWT とマイクロサービス 19 / 23

JWT とマイクロサービス 20 / 23

Kubernetes ではどうなっていくか Istio(Envoy) のJWT 検証 Origin authentication, also known as end­user authentication: verifies the original client making the request as an end­user or device. Istio enables request­level authentication with JSON Web Token (JWT) validation and a streamlined developer experience for Auth0, Firebase Auth, Google Auth, and custom auth. Envoy のJWT Authentication Filter This HTTP filter can be used to verify JSON Web Token (JWT). It will verify its signature, audiences and issuer. It will also check its time restrictions, such as expiration and nbf (not before) time. If the JWT verification fails, its request will be rejected. If the JWT verification succeeds, its payload can be forwarded to the upstream for further authorization if desired. JWT とマイクロサービス 21 / 23

JWT とマイクロサービス 22 / 23

おわり JWT とマイクロサービス 23 / 23