MicroProfile JWTによるスケーラブルでセキュアなマイクロサービス構築 -入門編(Part 1)-
富士通技術者ブログ~Javaミドルウェア~
2022年2月25日 初版
数村 憲治
Webアプリケーションの認証・認可システムはOAuth2を利用することが一般的になっています。しかし、モノリシックサービスでは問題なかったOAuth2の利用が、マイクロサービスアーキテクチャー(以下、MSA)ではスケーラビリティーを阻害する問題になることがあります。本特集では、MSAにおけるOAuth2利用時の問題を紹介した後、この問題を解決するMicroProfile JWTによるロールベースアクセス制御(以下、RBAC)を解説します。
マイクロサービスでの認可問題
あるサービスを提供する際に、特定の人だけにアクセスを許可したい場合があります。このような場合、OAuth2を使った認可システムを構築するのが一般的です。
図1:モノリシックサービスで従来型認可機構を使用した例
従来のモノリシックサービスでは、最初に認可情報を確認し、このサービスにアクセス可能な認可情報であるなら、そのサービス内で認可情報を共有するので、サービス内の機能が個々に認可サーバーへ問い合わせる必要はありませんでした。このようなモノリシックサービスを、例えば100個のマイクロサービスに分割したとします。そうすると、これまでは認可情報の確認は最初の1回だけで済んだものが、100個のマイクロサービスそれぞれで確認が必要となってしまいます。
図2:MSAで従来型認可機構を使用した例
そのため、前例のようにモノリシックサービスを単純にマイクロサービスに分割すると、認可サーバーへの負荷が100倍になってしまいます。マイクロサービスを増やせば増やすほどスケールしなくなるうえ、認可サーバーがSPOF(単一障害点)となり、システム全体の信頼性も損なうことになります。
MSAにおけるJSON Web Tokenの利用
JSON Web Token(以下、JWT)とは、JSON形式の属性情報(Claim)をURLセーフな表現にしたトークンです。MSAでは、認可情報をJSON形式で定義し、それをJWTとしてHTTPヘッダー(Authorizationヘッダー)に載せて対象サーバーに渡すことが一般的です。トークンを使うという点では従来型認可機構と同じですが、従来型ではトークン内に『具体的に何を許可するか』という情報は持っていませんでした。そのため、認可情報を認可サーバーに問い合わせる必要がありました。これに対して、JWTに具体的な許可情報を埋め込む機構を用いると、トークンの内容を確認するたびに、認可サーバーに問い合わせる必要がなくなります。
図3:JWTを利用した認可機構の例
このため、認可サーバーがSPOFにならず、マイクロサービスアーキテクチャーでもスケールする認可システムを構築することができます。
MicroProfile JWTとは
MicroProfile JWT(以下、MP JWT)とは、JWTをJavaのRESTfulサービスで使用するためのRBAC(Role Based Access Control)仕様です。アノテーションを使って、各RESTエンドポイントへのアクセス制御などが簡単にできるようになります。
なお、データやトークンの暗号化、JWTの作成等は、MP JWTの仕様範囲外です。
JWTの構成
JWTの中身がどのような構成になっているかを見ていきましょう。JWTは次の3つの部分から構成されています。
- ヘッダー
- ペイロード
- 署名
なお、JWTの詳細については、RFC7519を参照してください。
ヘッダー
ヘッダーは、このトークンがJWTであることを示す情報や暗号アルゴリズムをJSON形式で記載します。
ヘッダーの例
{
"typ": "JWT",
"alg": "ES256",
"kid": "key-1234"
}
MP JWTでは、"typ"には必ず"JWT"を指定します。また、"alg"には"RS256"または"ES256"などを指定します。MP JWTでヘッダーに指定できるものについては、以下の仕様書を参照してください。
- Required MP-JWT Headers(Eclipse MicroProfile Interoperable JWT RBAC)
- Recommended MP-JWT headers(Eclipse MicroProfile Interoperable JWT RBAC)
ペイロード
ペイロードには、認可情報をJSON形式で記載します。
ペイロードの例
{
"iss": "発行者",
"exp": 1668132671,
"iat": 1636596671,
"upn": "富士通花子",
"address": "東京都港区東新橋",
"groups": ["キツネさんチーム", "たぬきさんチーム"]
}
上記例におけるキーと値の意味は以下のとおりです。
iss | トークンの発行者 |
---|---|
exp | JWTの有効期限(1970年1月1日からの経過秒数) |
iat | JWTを発行した日時(1970年1月1日からの経過秒数) |
upn | java.security.Principalに相当する主体名(user principal name) |
address | 住所 |
groups | ロール |
MP-JWTにおけるペイロードの詳細については、必須項目と推奨項目を参照してください。
署名
署名は、ヘッダーとペイロードに対し実施します。以下のような手順で、ヘッダー、ペイロード、作成した署名を「.」で結合し、最終的なJWTにします。
-
ヘッダーをBase64URLでエンコード
-
ペイロードをBase64URLでエンコード
-
1の結果と2の結果を「.」で結合
-
3の結果に署名(MACの生成)
-
4の結果をBase64URLでエンコード
-
1と2と5の結果を「.」で結合
図4:JWTの構成
署名の詳細については、JSON Web Signatureを参照してください。
まとめと予告
今回のPart 1では、マイクロサービスアーキテクチャーにおける認可システムの課題と、その解決策であるMicroProfile JWTの紹介、およびJWTの構成内容や作成についてみてきました。次回Part 2では、Jakarta RESTful Web ServicesアプリケーションにおけるMicroProfile JWTの使用方法を紹介します。
本コンテンツに関するお問い合わせ
お電話でのお問い合わせ

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。