はじめに
Quarkus は JWT 認証に MicroProfile 仕様の MP-JWT (SmallRye 実装) を利用している。
この MP-JWT と Auth0 の仕様の競合により、両者の組み合わせでは RBAC が実現できない。
本投稿では原因となる両製品の仕様を記述する。
※ Quarkus のバージョンは Ver 0.22.0 (2019年9月 時点最新) とする。
仕様
MP-JWT の仕様 (制約)
MP-JWT では JWT 必須クレームに加え、権限情報を独自のクレーム groups
に設定する仕様となっている。
groups
を省略した場合、MP-JWT は JWT のパースに失敗する。
参照 : MicroProfile JSON Web トークンの構成 - IBM Knowledge Center
groups
クレーム名はプロパティ smallrye.jwt.path.groups
で別名を定義できる。
ただしこのクレーム名はパス解釈され、/
区切りでネストする。
smallrye.jwt.path.groups=realm/groups
上のように定義した場合、対応する JWT クレームは以下となる。
"realm" : {
"groups": ["bar", "foo"]
}
Auth0 の仕様 (制約)
Auth0 の ID Token はJWT の仕様に準拠している。
独自のクレームを定義する場合はクレーム名の先頭に URL 形式の namespace を付与する必要がある。(namespace は架空の URL で OK)
# OK
https://yourdomain.com/groups
#NG
groups
参照 : User profile claims and scope - Auth0 Docs
MP-JWT と Auth0 の仕様を合わせると
- Auth0 は
groups
代替クレームを提供可能、ただしクレーム名は/
を必ず含む URL 形式 - MP-JWT は
/
をネストとして解釈するため、URL 形式のクレーム名を Auth0 の期待通りにパースできない
…試合終了。
代替案
KeyCloak を利用する
代替、というより正攻法。
KeyCloak は公式にプラグインが提供されている。特段の理由がない限りこちらの利用をお勧めする。
認証のみ利用する
ユーザー認証のみ行い、機能への認可を不要とする場合は Auth0 を利用可能。
別投稿 にて記述した。
最後に
解決するには MP-JWT のクレーム名解釈の仕様変更か、Auth0 の独自クレーム名の制約緩和が必要です。
前者の実現性は低いとして、後者となった場合親切な方、コメント頂けると幸いです。
※ 「イヤそもそも使える」よって訂正はもっと歓迎です!