こんばんは。ritouです。 少し前に、このようなスライドを見かけました。
今回はこのCapability URLsにJWTを使ってみてはいかがかなというお話をします。
私ぐらいになるとこういうやつもeyJ派なので...https://t.co/7FodQaA8ap
— 👹秋田の猫🐱 (@ritou) 2020年8月11日
Capability URLs as a Bearer Token
挙げられている特徴や要件として
- 推測できてはいけない
- URLとして適切な長さ(ブラウザによって処理できないやつが出てこない)
ぐらいで、"えいち、てぃー、てぃー、ぴー、..." とラジオのDJが番組内で紹介できるぐらいの短さを求められたりしないのであれば、OAuth 2.0のBearer Tokenの要件と同等に捉えることもできそうです。
JWTの適用
JSON Web Token、正確には JSON Web Signature を使うことで
- 構造化されたデータを文字列にできる : リソースに一意に紐づけられるだけでなく、ちょっとしたパラメータを加えられる
- 改ざんされていないことを検証できる : 第3者が有効なURLを生成しにくい
という特徴を利用できます。
JWTといえばステートレス信仰が湧き上がって来るわけですが、ここでは一旦おいておきます。 JWTをCapability URLsに利用する際のポイントを整理すると
- 元々設計されているリソース識別子のエントロピーに影響しないURLが作成可能 : 任意のURLにアクセスできる確率の話は署名の方に依る
- 同じリソースに対して細かいパラメータを加えてやれば有効期限などのちょっとした制御もできる
- 無効化などの管理もJWT自体の識別子や全体のハッシュ値などを使えば それなりにできる
となるでしょう。 当然、
- JWTのPayloadに含まれる情報には気をつける必要がある(見られたくないデータは含まない)
- Payloadにたくさん入れすぎるとURLが長くなる(CWTワンチャン？)
というあたりには気をつける必要があるわけですが、十分実用に耐えうるのではないかと思います。
まとめ
- Capability URLs も Bearer Token の要件に近いのではないか
- JWTを適用することで得られるもの、気をつけるべき点をざっくり整理した
という感じです。 この手の機能の設計を行う際に、JWTの適用も選択肢に加えてみるのもいかがでしょうか？
それにしても私が数年前から罹患しているこの「何でもJWTで解決しようとしてしまういわゆるeyJ病」なかなか厄介です。 ではまた。
