認証と認可 Keycloak入門第5章を読んで|OAuthの認可コードフローをサンプルコードベースで解説

はじめに

認証と認可 Keycloak入門の第5章 OAuthに従ったAPI認可の実現を読んで、

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

サンプルコードの各処理と認可コードフローと照らし合わせながら解説を入れてみました。

 

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

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

 

MEMO

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

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

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

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

Keycloakで認証認可!!|APIの保護〜SPAのログイン機能、OIDC、 OAuthなど解説まとめ記事

 

認証と認可って何??OAuthの認可コードフローとは??

そもそも

認証と認可の違いとは??

認可コードフローとは??

 

の理解に自信がない方はまずこれらの記事を参照ください。

(図を用いて解説してたり、理解に役立つ別のおすすめサイトの紹介もしています。)

OAuth2.0の認可コードフローについて全体概要を解説 認証と認可 Keycloak入門第2章を読んでみて|特にOAuthとOIDCの違い中心に重要ポイントをまとめました。

 

 

KeycloakでAPI認可を実現するには??認可コードフローとkeycloakの設定とサンプルコード解説

API認可を体験するために、

認可される側のクライアント側のソースコード

リソースサーバ側のソースコードのサンプルコードが本とセットで用意されています。

 

これを本の解説通りにkeycloakの設定をして動作の確認をするのはkeycloakの学習に十分なるのですが、

 

この記事では、

認可コードフローを実現するために、サンプルコードベースでどう動いている

中身を少し追いかけて、さらに理解を深められたらと思います。

フローの全体像はこんな感じ

 

 

 

keycloakの認可エンドポイントへリダイレクト

 

 

クライアントアプリでブラウザ上でGet Tokenボタンを押下してから

Keycloakの認可エンドポイントへリダイレクトするまでをポイントに絞って確認していきます。

 

まず、リダイレクトURLをクライアントアプリが作成しているところはこの辺りです。

>>リダイレクトURLの生成箇所(github)

>>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の設定と、

実際の認可コードフローの全体の流れをまずは押さえられれば十分だと思います。

 

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください