釣りキチ翔平の備忘録 
はじめに
認証と認可 Keycloak入門の第２章 OAuthとOIDCの基礎知識を読んで、
実際にKeycloakを業務で利用している自分の観点で重要だと感じたポイント(特にOAuthとOIDCの違い中心に)をまとめました。
「Keycloakを導入検討していて、本を買って読んでみたけど理解が怪しい。。。」
という方に参考にして頂ければ幸いです。
2022/3/26追記
KeycloakでSpring Bootで作成したRestAPIを保護、
SPAにKeycloakのSSO機能でログイン機能を追加、
OIDCやOAuth2.0の違い解説などなどをまとめたまとめ記事を作りました。
興味のある方は是非みてください！！
Keycloakで認証認可！！｜APIの保護〜SPAのログイン機能、OIDC、 OAuthなど解説まとめ記事
OAuthとOIDCの違いは？？
OAuthは認可、OIDCは認証のためのプロトコルです。
OIDCはOAuthの認可コードフロー(KeycloakではStandard Flowと表記)がベースになってその拡張なので、
まずは認可コードフローの登場人物と具体的なフローについて理解することが重要だと思います！！！
(他にもOAuthのフローありますが、とりあえず認可コードフローを理解するだけでもOK)
本でも丁寧に解説してくれてますが、
もし、理解しきれなかった場合は、
僕も別の記事で一度まとめてあるので、よろしければそちら参照ください！！
OAuth2.0の認可コードフローについて全体概要を解説
ちなみに、僕はAuthleteの川崎さんの記事でOAuthの認可コードフローを勉強しました。
こちらもかなりわかりやすいです！！
OAuthとOIDCの登場人物
OAuthの認可コードフローと、OIDCのフローはほぼ同じなのですが、
登場人物に対する呼び名が異なります！！(僕は本を読むまでこんがらがってました)
クライアントについて補足
クライアントには大きく２つあります。
【コンフィデンシャルクライアント】
シークレットキーを機密に扱えるクライアント(サーバーサイドで動くアプリがクライアントになるケース)
【パブリッククライアント】
シークレットキーを機密に扱えないクライアント(SPAのフロントエンドがクライアントになるケース)
Keycloakでクライアントの設定をする際は、この辺り使い分けて設定が必要です。
(SPAでブラウザ上で動くアプリがクライアントになる際、
コンフィデンシャルクライアントにする意味ないよってどっかの記事で誰か指摘されてたの見かけたことある・・・)
IDトークンとアクセストークン
OAuthの認可コードフローではKeycloak(認可サーバ)からアクセストークンを発行してもらいます。
OIDCはOIDCフローでKeycloak(OP)からIDトークン＋アクセストークンが発行されます。
OIDCは認可コードフローとほぼ同じフローでアクセストークンも発行するので認可に利用することもでき、
これで認証と認可OAuth、OIDCがこんがらがってたんですよね。。。(僕の場合)
OAuthとOIDCの違いとしてこの点も抑えておくべきポイントかなと個人的には思います！！
ここからはおまけで・・・・
個人的には勉強になったことを書いておくと、
Keycloakが発行するトークンはJWTに改竄されても検知できるようにシグネチャを付与したJWS形式になっている。
JWTには複数のクレーム入っており、ユーザに独自の属性を持たせる(例えばユーザの所属先情報とか)場合、
マッパーという機能を使えばクレームを追加できる。
(ちなみに、、僕は現場でよくわからないままこの機能使ってました。)
JWSを解読できるようにするjwt.ioというのがあり、それを使ってとあるトークンを解読できるようにしたのがこんな感じです。
アクセストークン
IDトークン
クレームは紫のところで、ここにorganization_typeみたいな感じで所属先を追加した形の IDトークンにしたり、
さらに言うと、SSOで初回ログイン時にシステム固有のユーザ項目などはここに追加しておいて、
そこから値を取り出して初回登録する。などに使えます。
SSOの初回ログインの実装方法悩んでたんですが、、
今度これ試してみようと思います。
トークンとリフレッシュトークン
IDトークンやアクセストークンと同時にリフレッシュトークンがKeycloakからは発行されます。
(あえて発行させない設定などもあるけどそこは一旦置いときます)
リフレッシュトークンの目的は、
簡単に言うと、何度も何度も認証なり認可の作業をしたくないから利用します。
トークンの有効期限が切れてもリフレッシュトークンで新しいトークンを自動で発行できるイメージ。
本では、
トークンの有効期限は数分〜数十分、リフレッシュトークンの有効期限は数時間から数日を推奨されていました。
こうしておくと、トークンが盗まれても、数分くらいしか使えないようになります。
これもおまけですが・・・
以前、SPAにおけるアクセストークンやリフレッシュトークンの扱いって何がベストプラクティスなんだろう。。。
と悩んでた時期があり、
OAuth2.0のブラウザベースアプリ(SPA)のベストプラクティスに近いこれを参考にいろいろ考察していたのですが、
＞＞OAuth 2.0 for Browser-Based Apps draft-ietf-oauth-browser-based-apps-08
In particular, authorization servers:
o MUST either rotate refresh tokens on each use OR use sender-
constrained refresh tokens as described in [oauth-security-topics]
Section 4.13.2o MUST either set a maximum lifetime on refresh tokens OR expire if
the refresh token has not been used within some amount of timeo MUST NOT extend the lifetime of the new refresh token beyond the
lifetime of the initial refresh tokeno upon issuing a rotated refresh token, MUST NOT extend the lifetime
of the new refresh token beyond the lifetime of the initial出典：OAuth 2.0 for Browser-Based Apps draft-ietf-oauth-browser-based-apps-08
ここには、ざっくり言うと
リフレッシュトークンは使用する度にローテーションしなければならない。
ローテーションの際、元のリフレッシュトークンの有効期限を伸ばしてはいけない。
(有効期限をそのまま引き継いでローテーションしなさい)
と述べられていました。
KeycloakでもTokenの設定でこの辺りできるので、
SPAでフロントエンドにトークンを返却しなければならない場合は設定しておくべきかなと思います。
まとめ
今回は認証と認可 Keycloak入門第２章を読んでみて、
特にOAuthとOIDCの違い中心に重要ポイントをまとめました。
- OIDCはOAuthの認可コードフローがベースになっている(認可コードフローの理解重要)
- OIDCとOAuthの登場人物の呼び名は違う
- アクセストークンとIDトークンとリフレッシュトークンの関係
僕自身業務で使ってるけど、
本を読むと、結構ふわっと理解していたのだなと言うことに気づかされます。。。。
