認証と認可 Keycloak入門第４章を読んでみて｜Keycloakの用語とセッションとトークンの有効期限の関係

はじめに

認証と認可 Keycloak入門の第４章　Keycloakの基礎を理解するを読んで、

実際にKeycloakを業務で利用している自分の観点で重要だと感じた、

特に抑えておきたいKeycloakの基本的な概念とセッションとトークンの有効期限の関係についてまとめました。

「Keycloakを導入検討していて、本を買って読んでみたけど理解が怪しい。。。」

という方に参考にして頂ければ幸いです。

2022/3/26追記

KeycloakでSpring Bootで作成したRestAPIを保護、

SPAにKeycloakのSSO機能でログイン機能を追加、

OIDCやOAuth2.0の違い解説などなどをまとめたまとめ記事を作りました。

興味のある方は是非みてください！！

抑えるべきはざっくり以下4つです。

例えば、A社とB社にシステムを導入していて、認証方式や管理ユーザなどなど個別に異なる場合、

その各種設定範囲を分割するためにレルムがあります。

僕が現場で担当しているプロダクトもマルチテナントで動くように諸々設定をしているのですが、

導入先毎にレルムを分けて管理しています。

具体的なレルムの作成方法などは、

すでに結構丁寧に解説されているサイトなどもあるのでここでは省略します。

例えばOIDCのRPがKeycloak(OP)と連携するためのクライアントを作成する必要があったり、

リソースサーバがトークン検証の際、

Keycloakと連携するためのクライアントを作成する必要があったりします。

具体的なクライアントの作成方法は

すでに結構丁寧に解説されているサイトなどもあるのでここでは省略します。

Keycoakではユーザを管理でき、Keycloakがデフォルトで用意している属性(メールアドレス、ユーザ名など)

の他にユーザの属性情報(ユーザの職業情報とか)を追加で管理することができます。

また、グループ(ユーザが所属している組織のイメージ)、やロール(管理者権限、一般権限とか)も管理でき、

ユーザがどのグループでどのロールを持っているのかということが管理できます。

それによって、Aグループに所属しているユーザだけに参照できるようにする。

管理者権限を持つユーザのみ更新権限を与える。

などの制御が行えます。

これは見るのが早いので・・・

IDトークンにロール、グループ、属性追加をしてレルムにマッピングした例を見てください。

(IDトークンをデコードjwt.ioでデコード済み)

このようにユーザに追加した諸々の情報をIDトークンやアクセストークンのレルムとして追加したり、

OIDCのUserInfoエンドポイントで返却できるようにしたりする設定が、

プロトコルマッパー(クライアント単位で設定)やクライアントスコープ(クライアント横断で設定)です。

ちなみに今回はfrontendというクライアントを作って、そこにマッパーの設定をこんな感じで入れました。

有効期限の関係を意識しないものとして全部で4つあります。