釣りキチプログラマー翔平の備忘録 
はじめに
OAuthでRestAPIに認可機能を付与する際のkeycloakの設定手順をまとめました。
さらに、実際にサンプルコードの動作確認をしながら、
OAuthのベースとなっている認可コードフローのしくみも図解で確認しながらまとめています。
認証と認可とは？？OAuthの認可コードフローとは？？
認証と認可の違いや、
OAuthの仕組みのベースとなっている認可コードフロー
について以下の記事にまとめているので、
必要であればご覧ください。
認可コードフローを図解｜OAuth2.0(OIDC)の仕組みをSPAのSSO機能を例に解説
OAuthとOIDCの違い｜それぞれで登場する概念とIDトークンとアクセストークンなど解説
この記事は、この辺りの知識がある前提で解説しています。
keycloakでAPI認可｜認可コードフローとkeycloakの設定をサンプルコードと図解で解説
keycloakで認可機能を実現するにあたって、
まず、OAuthのベースになっている認可コードフローの流れを見ていきます。
全体の流れはこんな感じ
keycloakの認可エンドポイントへリダイレクト
クライアントアプリでブラウザ上でGet Tokenボタンを押下してから
Keycloakの認可エンドポイントへリダイレクトするまでをポイントに絞って確認していきます。
まず、リダイレクトURLをクライアントアプリが作成しているところはこの辺りです。
＞＞keycloakからのリダイレクト戻り先を設定している箇所(github)
＞＞リダイレクトURLのパラメータのプロパティ(github)
認可エンドポイントへリダイレクトする最終的なパラメータにはこれらを設定しています。
- response_type：code(認可コードフローを表す)
- redirect_uri：localhost:8081/gettoken(keycloakからの戻り先のURI)
- client_id：demo-client
- scope：未指定(何の権限を与えるかを表す)
client_idをこのパラメータに指定するため、
keycloak側にはこれに合わせてdemo-clientを事前に作成する必要があります。
また、
redirect_uriの/gettokenを指定された際にそれが悪意のあるユーザが指定したリダイレクト先
(オープンリダイレクト攻撃)の場合はアクセスをブロックしたいため、
事前にValid Redirect URIsを指定します。
この例では空ですが、
例えばこの認可としては残高参照だけさせたいといった、
権限を与える範囲をコントロールするための設定をscopeパラメータで行います。
keycloakの認可エンドポイントからリダイレクトするとログイン画面が開きます。
keycloakで用意されるログイン画面で認証と同意画面で認可
ログイン画面でIDとパスワードを入力してログイン(認証)し、
次の同意画面で、
クライアントアプリに権限を与えることを同意します。
今回はscopeを指定していない認可コードフローですが、
下の例で同意を求められているのはkeycloakのデフォルトスコープです。
keycloakから設定したリダイレクトURIに認可コード返却
認証と認可が完了したら、指定のredirect_uriへ認可コード付きでリダイレクトされます。
HTTP/1.1 302 Found
Location: http://localhost:8081/gettoken?session_state=887b4c35-a695-4d37-a8f2-f2e9429ee86f&code=854634a6-b461-4240-838a-43cf68ce18e0.887b4c35-a695-4d37-a8f2-f2e9429ee86f.46b73d87-1634-4ae6-8298-f35662d5bb42
リダイレクト先に指定した/gettokenになっていることと、
codeとして認可コードがセットされてリダイレクトされていることがわかります。
keycloakのトークンエンドポイントからアクセストークンとリフレッシュトークンを取得
リダイレクトで/gettokenへアクセスすると、
クライアントアプリでは
keycloakのトークンエンドポイントからアクセストークンとリフレッシュトークンを取得します。
＞＞必要なパラメータを詰めてトークンエンドポイントをコールしている箇所(github)
keycloakでclient作成時に発行されたシークレットキー、
認可エンドポイントからのリダイレクトで取得した認可コード
などを設定してPOSTメソッドでトークンエンドポイントをコールしていることがわかります。
また、受け取ったアクセストークンやリフレッシュトークンをセッションスコープで
クライアントアプリで保持しています。
(そうしないとアクセストークン発行のための認証と認可を何度も行うことになる)
＞＞アクセストークンやリフレッシュトークンをセッションスコープで保持する箇所(github)
ここまでの流れがOAuthの認可コードフロー(アクセストークンを発行するまでのフロー)です。
ここまで確認した通り、
認可コードフローではリダイレクトで各種パラメータの受け渡しを行うので、
パラメータの書き換えや横取りなど攻撃者が付け入る隙があります。
例えば、認可コードフローが横取りされた認可コードを使われても、
PKCEで対策したりなど。
そのあたりは追々学習するとして、
ここまでの基本的な流れをkeycloakの設定と、
実際の認可コードフローの全体の流れをまずは押さえられれば十分だと思います。
おまけ
KeycloakでSpring Bootで作成したRestAPIを保護、
SPAにKeycloakのSSO機能でログイン機能を追加、
OIDCやOAuth2.0の違いなど図解などなどをまとめ記事にしました。
是非ご覧ください！！
