認証基盤を素早く整えられる

改善してほしいポイント

機能が豊富なぶん、初期設計では用語と責務の整理が必要です。たとえば通常のユーザーログイン、APIのaudience、M2M application、refresh token、JWKSなどを混同すると、どのトークンをどこで検証するのか分かりにくくなります。
また、設定項目が多いため、ドキュメントを読みながら正しく構成する必要があります。特に本番運用では、client secretの保管場所、audienceの切り分け、許可するcallerの管理などをチーム内で明文化しておくのが重要だと思います。

どのような課題解決に貢献しましたか？どのようなメリットが得られましたか？

管理画面のログイン、API側でのJWT検証、外部アダプタからAPIへのM2M認証を同じ認証基盤上で整理できました。ログインUIをアプリ側に作り込まず、API側はbearerトークンを検証するだけにできるため、フロントエンドとバックエンドの責務分離がしやすくなりました。

検討者へお勧めするポイント

小規模なログイン導入だけならすぐ使い始められますが、APIや複数のサービスをまたぐ構成では、最初に「誰がログインするのか」「どのAPIのaudienceを使うのか」「M2M callerは何か」「tokenをどこで検証するのか」を図にしておくと導入がスムーズです。認証を自前実装しないメリットは大きいので、将来的に認証要件が増えそうなサービスでは早めに採用する価値があると思います。