0LINEはじめに以下大きく2点について、Keycloakを業務で実際に利用している自分の観点で押さえておくべきポイントに絞ってまとめました。抑えるべきはざっくり以下4つです。Keycloakの設定周り一式を分割できるレルムKeycloakと連携するために必要なクライアントユーザとユーザに付与できる情報(属性情報、ロール、グループ)トークンにユーザ関連の情報をマッピングする仕組み(プロトコルマッパー、クライアントスコープ)Keycloakの設定周り一式を分割できるレルム例えば、A社とB社にシステムを導入していて、認証方式や管理ユーザなどなど個別に異なる場合、その各種設定範囲を分割するためにレルムがあります。導入先毎にレルムを分けて管理しています。具体的なレルムの作成方法などは、すでに結構丁寧に解説されているサイトなどもあるのでここでは省略します。Keycloakと連携するために必要なクライアント例えばOIDCのRPがKeycloak(OP)と連携するためのクライアントを作成する必要があったり、リソースサーバがトークン検証の際、Keycloakと連携するためのクライアントを作成する必要があったりします。具体的なクライアントの作成方法はすでに結構丁寧に解説されているサイトなどもあるのでここでは省略します。ユーザとユーザに付与できる情報(属性情報、ロール、グループ)Keycoakではユーザを管理でき、Keycloakがデフォルトで用意している属性(メールアドレス、ユーザ名など)の他にユーザの属性情報(ユーザの職業情報とか)を追加で管理することができます。)も管理でき、ユーザがどのグループでどのロールを持っているのかということが管理できます。それによって、Aグループに所属しているユーザだけに参照できるようにする。管理者権限を持つユーザのみ更新権限を与える。トークンにユーザ関連の情報をマッピングする仕組み(プロトコルマッパー、クライアントスコープ)これは見るのが早いので・・・IDトークンにロール、グループ、属性追加をしてレルムにマッピングした例を見てください。(IDトークンをデコードjwt.ioでデコード済み)このようにユーザに追加した諸々の情報をIDトークンやアクセストークンのレルムとして追加したり、OIDCのUserInfoエンドポイントで返却できるようにしたりする設定が、プロトコルマッパー(クライアント単位で設定)やクライアントスコープ(クライアント横断で設定)です。ちなみに今回はfrontendというクライアントを作って、そこにマッパーの設定をこんな感じで入れました。有効期限の関係性を意識しないものとして全部で4つあります。Idleセッションやリフレッシュトークンの有効期限を短くするとログイン(再度認証や認可のやり直し)を頻繁に行うことになるので、ユーザビリティとのトレードオフで決めることになります。漏洩のリスクや被害影響を最低限に抑えることができます。具体的なKeycloakの設定画面はこんな感じです。これらの有効期限の関係を認可コードフローの時間軸と照らし合わせるとこんな感じです。必要であればこちらもご覧ください認可コードフローを図解|OAuth2.0(OIDC)の仕組みをSPAのSSO機能を例に解説まとめ今回はKeycloakを利用する上での基本的な概念と、セッションとアクセストークン、IDトークン、リフレッシュトークンの有効期限の関係についてまとめました。Keycloakを利用する上で抑えておくべき概念は以下の4つです。Keycloakの設定周り一式を分割できるレルムKeycloakと連携するために必要なクライアントユーザとユーザに付与できる情報(属性情報、ロール、グループ)トークンにユーザ関連の情報をマッピングする仕組み(プロトコルマッパー、クライアントスコープ)逆にこの辺りが抑えられれば認証サーバや認可サーバとしてのKeycloakを設定はある程度正しく行えるようになると思います。僕はこの辺り抑えてないまま設定していたので、、、ちょこちょこ良くない設定をしていました。Application)にKeycloakのSSO機能でログイン機能を追加したり、OIDCやOAuth2.0の違い解説などなどのまとめ記事を作りました。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。