1. 目次

1. 目次
2. 概要
3. CIBA(シーバ)とは何か？
4. 今回試す全体像の説明
5. 今回使う環境の説明
6. CIBAを検証するための検証用データの作成・確認
7. リクエストベースでの解説
8. 後書き

2. 概要

shiba チームの中村です。今回は6月18日にリリースされた Keycloak14.0.0 を用いてOpenID Connect Client Initiated Backchannel Authentication(CIBA)を試してみました。

CIBAのサポートはKeycloakのバージョン13.0.0から有効化されましたが、現在テクノロジープレビューの状態であり、デフォルト無効であったり、管理画面のGUI上の変更だけでは設定できない項目などがあったので、皆さんへの共有のためにこの記事を作成しました。

• Keycloak 13.0.0 released
• Keycloak 14.0.0 released

今回の記事で説明する箇所

また、今回の記事では主に下記の部分について解説していきます。

• KeycloakでCIBAを有効にする設定
• KeycloakでCIBAを試す際の
  • 変更・確認が特に必要な設定
  • 簡易シーケンス図
  • curlコマンドのサンプル 及び 各フィールドの説明

今回の記事で説明しない箇所

下記の内容については詳細な解説は割愛させていただきます。参考になる公式のリンクを貼っておいたので必要に応じて確認お願いします。

• Keycloakのドキュメントで明らかに明確な手順の詳細な解説
  • 管理コンソールへのログイン
  • レルムの作成方法
  • ユーザーの作成方法
  • クライアントの作成方法
• 補助となる Rails の簡易アプリケーションの実装方法
• Docker 及びDocker Compose の説明

3. CIBA(シーバ)とは何か？

CIBAとは、OpenID Connect Client Initiated Backchannel Authentication の略称であり、OpenIDFoundationの MODRNA(Mobile Operator Discovery, Registration & autheNticAtion)のワーキンググループによって作られた仕様です。

認証したいユーザの有効な識別子を取得できるRPが、エンドユーザとの対話(ユーザーのブラウザなどを介しての対話など)を行わずに、ユーザを認証するための対話フローを開始できるようにするための、新しい認証フローです。

この仕様はパブリックレビュー期間が2018年12月14日に開始され、2019年2月4日に Implementer's Draftとして承認されました。

この仕様をざっくり説明すると、下記のような流れを取ります。

1. クライアントはOPのバックチャネル認証エンドポイントに認証リクエストを送信。
2. 受信したOPはバックグラウンドでユーザーを認証しようとし、認証を識別する一意の識別子を返却。
3. クライアントは polling、ping、push のいずれかの方法で、IDトークン、アクセストークン、オプショナルで場合によっては更新トークンを取得。

より詳しい詳細はこちらをご確認ください。

• OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 draft-04

4. 今回試す全体像の説明

次に今回試す全体像をご説明します。

今回はKeycloakでCIBAのポーリングモードを用いて検証します。ポーリングモードで今回試す処理の簡易のシーケンス図が下記になります。

上記のポーリングでやりとりするケースのシーケンスの中で緑色の点線に囲まれた箇所がCIBAに該当する部分で、主に下記の2箇所です。

• Authentication Request とそのレスポンス
• Token Request とそのレスポンス

ではそれ以外の下記はなにかというと、Keycloak側の仕様です。

• Authentication Delegation Requestとそのレスポンス
• Authentication Result Notification とそのレスポンス

というのもそもそもCIBAはバックエンドの認証を開始する方法は仕様として定義しておりますが、ユーザーをどのように認証するかということは定義しておりません。

また、今回のフローではユーザー認証の部分をスキップし、認証したものとして 認証結果を通知するリクエスト(図での Authentication Result Notification)を送って試します。

勿論よく聞くようなプッシュ通知を送り、確認されたら Authentication Result Notification を送るような実装も考えられます(こちらは別途記事化するかもしれません)。ですが今回の記事では一旦CIBA部分にだけ絞ってお話していきます。

5. 今回使う環境の説明

version: '3.8'

services:
  keycloak:
    container_name: keycloak
    image: jboss/keycloak:14.0.0
    command: -b 0.0.0.0 -Dkeycloak.profile.feature.ciba=enabled
    ports:
      - "8088:8080"
    volumes:
      - ./docker/keycloak/demo-config/standalone-ha.xml:/opt/jboss/keycloak/standalone/configuration/standalone-ha.xml
    environment:
      KEYCLOAK_USER: admin
      KEYCLOAK_PASSWORD: password
  
  authn-server:
    container_name: authn-server
    build:
      context: ./docker/authn-server
    command: bash -c "rm -f tmp/pids/server.pid && bundle e rails s -p 3000 -b '0.0.0.0'"
    ports:
      - 3000:3000
    volumes:
      - ./docker/authn-server:/my_app

<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="https://backend.internal.example.com/auth"/>
        </properties>
    </provider>
</spi>

より詳しい詳細はこちらをご確認ください。

• Keycloak: provider-setting 

volumes:
  - ./docker/keycloak/demo-config/standalone-ha.xml:/opt/jboss/keycloak/standalone/configuration/standalone-ha.xml

<subsystem xmlns="urn:jboss:domain:keycloak-server:1.1">
    ※多くの処理
</subsystem>

<spi name="hostname">
    <default-provider>${keycloak.hostname.provider:default}</default-provider>
    <provider name="default" enabled="true">
        <properties>
            <property name="frontendUrl" value="${keycloak.frontendUrl:}"/>
            <property name="forceBackendUrlToFrontendUrl" value="false"/>
        </properties>
    </provider>
    <provider name="fixed" enabled="true">
        <properties>
            <property name="hostname" value="${keycloak.hostname.fixed.hostname:localhost}"/>
            <property name="httpPort" value="${keycloak.hostname.fixed.httpPort:-1}"/>
            <property name="httpsPort" value="${keycloak.hostname.fixed.httpsPort:-1}"/>
            <property name="alwaysHttps" value="${keycloak.hostname.fixed.alwaysHttps:false}"/>
        </properties>
    </provider>
</spi>
<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="http://authn-server:3000/api/v1/auth"/>
        </properties>
    </provider>
</spi>

まずは任意のレルムを作成してください。今回の記事ではレルムの名前は SampleRealm で作成します。

今後の文章ではレルム名の部分を SampleRealm として説明していくので、今後の資料では適宜自分の環境に合わせて読み替えてください。

ユーザーの作成

次にユーザーを作成します。今回の記事では下記の値で作成します。

今後の文章ではユーザーの値を上記の値として説明していくので、今後の資料では適宜自分の環境に合わせて読み替えてください。

Usernameは任意の値で問題ありませんが、後々の手順で使用する機会があるため、検証時はわかりやすい名前のほうがよいかもしれません。

クライアントの作成

クライアントを作成します。今回の記事では下記の値で作成します。

備考: Root URL は今回のフローでは登録不要です。

作成後の Test-client の Setting タブで下記の変更を行っていきます。

1. Access Type のセレクトボックスの値を public から confidential に変更
2. Standard Flow Enabled を ON から OFF に変更
   補足: CIBAのフローではリダイレクト用のURIの登録は不要です。ですが、デフォルトだと他のフローのサポートのために、リダイレクト用のURI登録が必要になります。そのため Standard Flow Enabled を意図的に無効にします。例えば、仮に ON のままクライアントを保存しようとすると次のエラーが表示されます。

   Error! You must specify at least one redirect uri

3. OIDC CIBA Grant Enabledのチェックを OFF から ON に変更

上記の設定が終わり次第 Save からクライアントに対する設定を保存してください。

クライアントのシークレットトークンの確認

Test-client の Credentials タブで Secret の値を確認します。今回の例では仮に 2ae6d81d-bc78-434e-a7b8-985921e0d47b とします。この値は各環境で変わります。今後の資料では適宜自分の環境に合わせて読み替えてください。

Client Authenticator は初期値のままで問題ありません。念の為 Client and Secret であることを確認しておいてください。

CIBAの設定の確認・変更

レルムのAuthenticationのConfigureの画面にCIBA Policy というタブがあると思うので開いてください。

サンプルのようなdockerの設定と、レルム名にしている場合は下記のようなURLで開くこともできます。 http://localhost:8088/auth/admin/master/console/#/realms/SampleRealm/authentication/flows

各項目を簡単に説明していきます。

今回の検証では各リクエストに着目して少しずつ確認していくため、検証途中で auth_req_id の有効期限切れを迎えないようにExpires Inの設定を "600" に変更しておきしょう。

より詳しい詳細はこちらをご確認ください。

• Keycloak: CIBA Policy

7. リクエストベースでの解説

ではもう1度、簡易シーケンス図を見てみましょう。

リクエストとレスポンスに適当な番号(①~⑩)をつけて順に解説していきます。

大まかなかたまりとしては、

① Authentication Request
② Successful Authentication Request Acknowledgement
③ Authentication Delegation Request
④ Response (Authentication Delegation Requestのレスポンス)

①~④は、クライアントがKeycloakに認証を要求する部分です。内部でKeycloakはAutentication entityに認証を委任するリクエスト(②〜③)を送信します。

⑤ Token Request
⑥ Token Error Response

⑤~⑥は、認証を終えていない状態でトークンリクエストを行い
トークンエラーレスポンスを受け取る部分です。

⑦ Authentication Result Notification
⑧ Response (Authentication Result Notificationのレスポンス)

⑦~⑧は認証の結果をAutentication entityからKeycloakに通知を行う部分です。今回のケースでは⑦で正常に完了したものとして通知を行います。

⑨ Token Request
⑩ Successful Token Response

⑨~⑩は認証が正常に完了している状態でトークンリクエストを行う部分です。⑩のレスポンスを⑥のレスポンスと比較して確認してください。

では①番から順にリクエストを見ていくことにしましょう。

① Authentication Request

CIBAのフローはまず認証を要求するリクエストから始まります。

このリクエストは、HTTP POST メソッドを使用し、パラメータを application/x-www-form-urlencoded 形式でHTTPリクエストのBodyに含め送信します。

また、クライアントの認証方式に関しては OpenID Connect Core 1.0 で、client_secret_basic として説明されているような、Basic認証の形式を用いて行っていきます。

この形式は クライアントIDとクライアントシークレットをコロン(:)ではさんで結合しbase64化したものを Authorization ヘッダーに載せます。私の設定の場合は、クライアントIDが test-client で クライアントシークレットが 2ae6d81d-bc78-434e-a7b8-985921e0d47b なので、Macでのコマンドの一例だと下記のようになります。

$ echo -n 'test-client:2ae6d81d-bc78-434e-a7b8-985921e0d47b' | openssl base64

dGVzdC1jbGllbnQ6MmFlNmQ4MWQtYmM3OC00MzRlLWE3YjgtOTg1OTIxZTBkNDdi

今回使うヘッダーは下記になります。

Bodyに含ませる値は下記になります。

またリクエストURLには レルム名 を含んでおります。各自作成したレルム名で読み替えてください。http://localhost:8088/auth/realms/{レルム名}/protocol/openid-connect/ext/ciba/auth

より詳しい詳細はこちらをご確認ください。

• Keycloak: Backchannel Authentication Endpoint
• OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 draft-04 7.1. Authentication Request 

サンプルの場合はこのようになります。http://localhost:8088/auth/realms/SampleRealm/protocol/openid-connect/ext/ciba/auth

curl -X POST \
   -H "Content-Type:application/x-www-form-urlencoded" \
   -H "Authorization:Basic dGVzdC1jbGllbnQ6MmFlNmQ4MWQtYmM3OC00MzRlLWE3YjgtOTg1OTIxZTBkNDdi" \
   -d "scope=openid％20email％20example-scope" \
   -d "login_hint=cl-taro" \
   -d "binding_message=test message 0001" \
 'http://localhost:8088/auth/realms/SampleRealm/protocol/openid-connect/ext/ciba/auth'

{
    "auth_req_id": "eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..iazuIbFU1q16EjLHwBI-aQ.RAnmpznLSmM3UF75kK59-5cTVBlrSbXDXJQqZjQg9FScQSh_12UhxP5XExEDaDq_0m2viZ_mGFs7O0wq_LQ1sfxAd9uJd2UpD2p8XWlrPyl16FE6evHRjDGCGipvDkjTeBFlrTTapGcvPmxnSH_uu8XJeY_tGSWSSg-WxSAnDYB9FvjkfJDsfFQdU2_sOI2LBRnQlCuJBAdEkRhyQNQliSCE9cy9Zo9MWmCrVcDBft0_pYa3DIbfHxFs6ITqlb6_B9zEIVWZJsq2mcj9utTRxsR4B7fOJ4gP-e6MmmoIgNsTWG_HHkv-dwo9_rhCkSCIqpjvXrSkDccTz3BQvYD1xzxeuaod-2L31wp3donFonEnI5FPwb0BTwMPZ0rH_f6Dmee_RW9cBIGfBz3wGT7K9nHDU1OcyQdZtRqUuzR6GSnjFjNVRy_zry-0ujs3QgWS2rNHlQQqkQAXY6qpncVBSAkGGCf8dlgU3S31152MKtles3LVhKFUETybNhPsWFIqpkIPPZ0Y5qWksMGsEyNu49LIM1eqpoV2jTPAg9re7Cx9tdZr_XteuqREIZchJmYuEMmhk6H-_lTa9AfsL1db3pLpL-PwOZltmwcHOUwEcpIjqr91hZ-CdgzQvhNOJHfJyBRxpreHqDxIs7tBR8VGwFmtKiLKOu-mGuFnaICFwFHA1DgIFSpN9Tret4CoFqWjF50XTzjYkwKrqCQYIul7BWENDWcDwLA1JE5dU5LOZBn1HykSwerQceOlX9wcktgO9ajP9au9twggSlyy1rWSm0FgIBGULeUxgmD6hroyLIlZYsUYnOH2Ur2W9fIq0j7PAvznq5JC2OWWB4OtkeANeSxvEzle8M1Y-97n91M3tXogUdOQccy9ahUD15lzpSUoHFNpajr1IXVLTleqCpI-Gw.mfS4kUF5fPO4ZTCQNL3CvQ",
    "expires_in": 600,
    "interval": 5
}

このJSON形式のデータを簡単に説明していくと、

auth_req_id は 後の ⑤ Token Request のリクエストに使いますので、任意の媒体にメモしておいてください。

より詳しい詳細はこちらをご確認ください。

• OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 draft-04 7.3. Successful Authentication Request Acknowledgement 

③ Authentication Delegation Request

KeycloakにCIBAの仕様に沿った ①のAuthentication Request のリクエストが届くと、KeycloakはAuthentication entityに認証を委任するリクエスト(Authentication Delegation Request)をHTTP POST メソッドを使用して送ります。

このリクエストのヘッダーは下記になります。

<spi name="ciba-auth-channel">
    <default-provider>ciba-http-auth-channel</default-provider>
    <provider name="ciba-http-auth-channel" enabled="true">
        <properties>
            <property name="httpAuthenticationChannelUri" value="http://authn-server:3000/api/v1/auth"/>
        </properties>
    </provider>
</spi>

④ Response (③ Authentication Delegation Request のレスポンス)

③ Authentication Delegation Request のレスポンス(④)として必要な用件は、 HTTP status code として 201 を返却することだけです。

ただし、Authentication entityの実装としては ③ Authentication Delegation Request で受け取った Authorization ヘッダーの値を、後の ⑦ Authentication Result Notification のリクエストに使いますので、任意の媒体に記録しておいてください。

⑤ Token Request

このリクエストはトークンを要求するリクエストです。
CIBAの仕様では、トークンをやりとりする方法として下記の3パターンがあります。

• Poll Mode
• Ping Mode
• Push Mode

ただし、Keycloak は poll のみに対応しており、デフォルトも poll です。また、このポーリングの処理は ① Authentication Request の レスポンス(②) にある、 interval のタイミングより短い間隔でポーリングを行うとエラーが返ってくるため注意が必要です。

このリクエストのヘッダーは下記になります。

Bodyに含ませる値は下記になります。

サンプルの CURL文としては下記になります。

curl -X POST \
   -H "Content-Type:application/x-www-form-urlencoded" \
   -H "Authorization:Basic dGVzdC1jbGllbnQ6MmFlNmQ4MWQtYmM3OC00MzRlLWE3YjgtOTg1OTIxZTBkNDdi" \
   -d "grant_type=urn:openid:params:grant-type:ciba" \
   -d "auth_req_id=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..iazuIbFU1q16EjLHwBI-aQ.RAnmpznLSmM3UF75kK59-5cTVBlrSbXDXJQqZjQg9FScQSh_12UhxP5XExEDaDq_0m2viZ_mGFs7O0wq_LQ1sfxAd9uJd2UpD2p8XWlrPyl16FE6evHRjDGCGipvDkjTeBFlrTTapGcvPmxnSH_uu8XJeY_tGSWSSg-WxSAnDYB9FvjkfJDsfFQdU2_sOI2LBRnQlCuJBAdEkRhyQNQliSCE9cy9Zo9MWmCrVcDBft0_pYa3DIbfHxFs6ITqlb6_B9zEIVWZJsq2mcj9utTRxsR4B7fOJ4gP-e6MmmoIgNsTWG_HHkv-dwo9_rhCkSCIqpjvXrSkDccTz3BQvYD1xzxeuaod-2L31wp3donFonEnI5FPwb0BTwMPZ0rH_f6Dmee_RW9cBIGfBz3wGT7K9nHDU1OcyQdZtRqUuzR6GSnjFjNVRy_zry-0ujs3QgWS2rNHlQQqkQAXY6qpncVBSAkGGCf8dlgU3S31152MKtles3LVhKFUETybNhPsWFIqpkIPPZ0Y5qWksMGsEyNu49LIM1eqpoV2jTPAg9re7Cx9tdZr_XteuqREIZchJmYuEMmhk6H-_lTa9AfsL1db3pLpL-PwOZltmwcHOUwEcpIjqr91hZ-CdgzQvhNOJHfJyBRxpreHqDxIs7tBR8VGwFmtKiLKOu-mGuFnaICFwFHA1DgIFSpN9Tret4CoFqWjF50XTzjYkwKrqCQYIul7BWENDWcDwLA1JE5dU5LOZBn1HykSwerQceOlX9wcktgO9ajP9au9twggSlyy1rWSm0FgIBGULeUxgmD6hroyLIlZYsUYnOH2Ur2W9fIq0j7PAvznq5JC2OWWB4OtkeANeSxvEzle8M1Y-97n91M3tXogUdOQccy9ahUD15lzpSUoHFNpajr1IXVLTleqCpI-Gw.mfS4kUF5fPO4ZTCQNL3CvQ" \
 'http://localhost:8088/auth/realms/SampleRealm/protocol/openid-connect/token'

より詳しい詳細はこちらをご確認ください。

• OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 draft-04 10.1. Token Request Using CIBA Grant Type 

⑥ Token Error Response

この資料では Token Request を認証されていない状態で送ったケースと、認証が正常に完了している状態で送ったケースでそれぞれの状態のレスポンスを紹介していきます。

⑥はまず認証されていないケースのレスポンスです。レスポンスはHTTPステータスコード400で application/json 形式で送られてきます。レスポンスを整形すると下記のようになります。 今回のケースでは認証が済んでいないので、認証要求が保留となっているという情報が含まれています。

{
    "error": "authorization_pending",
    "error_description": "The authorization request is still pending as the end-user hasn't yet been authenticated."
}

このJSON形式のデータを簡単に説明していくと下記のようになります。

今回のエラーは、エンドユーザーがまだ認証されていないため、認証要求はまだペンディングされていることを示しています。

より詳しい詳細はこちらをご確認ください。

• OpenID Connect Client-Initiated Backchannel Authentication Flow - Core 1.0 draft-04 11. Token Error Response 

⑦ Authentication Result Notification

このリクエストは 認証結果をAuthentication entity から Keycloak に通知するリクエストです。

このリクエストのヘッダーは下記になります。

curl -i -X POST \
   -H "Content-Type:application/json" \
   -H "Authorization:Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJVZW9OQjYxbGt3ZGhJX1ctOU02S2haUksxWFpKdHdjd0pMQ3dJVFA1dTd3In0.eyJleHAiOjE2MjY3MTQzNTAsImp0aSI6IjNiYzRmNTkwLTQ0MmMtNDQ0ZS04YWU0LWRhODcxYmM5MmFkOCIsImlzcyI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4OC9hdXRoL3JlYWxtcy9TYW1wbGVSZWFsbSIsImF1ZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6ODA4OC9hdXRoL3JlYWxtcy9TYW1wbGVSZWFsbSIsInN1YiI6ImM4Zjg4YzliLTA2YTUtNDgwNy1iZjJmLTYxMzVjNjBhMDY4NiIsInR5cCI6IkJlYXJlciIsImF6cCI6InRlc3QtY2xpZW50In0.ivP4wN8wzLuOpmj6GaUxulmLxvuiXKvAQAl2ifBklm6iVJtJNiCZ24pcTw0GrE7SjBrn6SblO2eAscb1gQyIQGWZohbav0KZbhL37ZDlqK9ZYRNE0nWHYspBsB0kVR-Svj58BrGOvCuotmNrz5nPOgYjvlUl5V_d7mSxyYGUZ-3IBFsOvqo_aqKD2336ygjx_TDFTZ1LLjFA7cUAE6iLnFYPmFexYJrls7jvUI4OiJyIYMq3okIYhteZjeZSQKmz3PeMkSUl3W6qe4QoI7245Y7a862QbQOG7wqzJouYLwJVrzqtjbluWZMToy3A-oOEJk5HtAC59YMgMRUOGU9unA" \
   -d \
'{
  "status":"SUCCEED"
}' \
 'http://localhost:8088/auth/realms/SampleRealm/protocol/openid-connect/ext/ciba/auth/callback'

{
    "type": "application",
    "subtype": "json",
    "parameters": {},
    "wildcardType": false,
    "wildcardSubtype": false
}

curl -X POST \
   -H "Content-Type:application/x-www-form-urlencoded" \
   -H "Authorization:Basic dGVzdC1jbGllbnQ6MmFlNmQ4MWQtYmM3OC00MzRlLWE3YjgtOTg1OTIxZTBkNDdi" \
   -d "grant_type=urn:openid:params:grant-type:ciba" \
   -d "auth_req_id=eyJhbGciOiJkaXIiLCJlbmMiOiJBMTI4Q0JDLUhTMjU2In0..iazuIbFU1q16EjLHwBI-aQ.RAnmpznLSmM3UF75kK59-5cTVBlrSbXDXJQqZjQg9FScQSh_12UhxP5XExEDaDq_0m2viZ_mGFs7O0wq_LQ1sfxAd9uJd2UpD2p8XWlrPyl16FE6evHRjDGCGipvDkjTeBFlrTTapGcvPmxnSH_uu8XJeY_tGSWSSg-WxSAnDYB9FvjkfJDsfFQdU2_sOI2LBRnQlCuJBAdEkRhyQNQliSCE9cy9Zo9MWmCrVcDBft0_pYa3DIbfHxFs6ITqlb6_B9zEIVWZJsq2mcj9utTRxsR4B7fOJ4gP-e6MmmoIgNsTWG_HHkv-dwo9_rhCkSCIqpjvXrSkDccTz3BQvYD1xzxeuaod-2L31wp3donFonEnI5FPwb0BTwMPZ0rH_f6Dmee_RW9cBIGfBz3wGT7K9nHDU1OcyQdZtRqUuzR6GSnjFjNVRy_zry-0ujs3QgWS2rNHlQQqkQAXY6qpncVBSAkGGCf8dlgU3S31152MKtles3LVhKFUETybNhPsWFIqpkIPPZ0Y5qWksMGsEyNu49LIM1eqpoV2jTPAg9re7Cx9tdZr_XteuqREIZchJmYuEMmhk6H-_lTa9AfsL1db3pLpL-PwOZltmwcHOUwEcpIjqr91hZ-CdgzQvhNOJHfJyBRxpreHqDxIs7tBR8VGwFmtKiLKOu-mGuFnaICFwFHA1DgIFSpN9Tret4CoFqWjF50XTzjYkwKrqCQYIul7BWENDWcDwLA1JE5dU5LOZBn1HykSwerQceOlX9wcktgO9ajP9au9twggSlyy1rWSm0FgIBGULeUxgmD6hroyLIlZYsUYnOH2Ur2W9fIq0j7PAvznq5JC2OWWB4OtkeANeSxvEzle8M1Y-97n91M3tXogUdOQccy9ahUD15lzpSUoHFNpajr1IXVLTleqCpI-Gw.mfS4kUF5fPO4ZTCQNL3CvQ" \
 'http://localhost:8088/auth/realms/SampleRealm/protocol/openid-connect/token'

{
    "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJVZW9OQjYxbGt3ZGhJX1ctOU02S2haUksxWFpKdHdjd0pMQ3dJVFA1dTd3In0.eyJleHAiOjE2MjY3MTc0MjgsImlhdCI6MTYyNjcxNzEyOCwianRpIjoiOWQ4Y2JlOTQtZTMxYy00ZGQ5LWJkYmItM2E4ZTQ4Y2Q5YTUzIiwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDg4L2F1dGgvcmVhbG1zL1NhbXBsZVJlYWxtIiwiYXVkIjoiYWNjb3VudCIsInN1YiI6ImM4Zjg4YzliLTA2YTUtNDgwNy1iZjJmLTYxMzVjNjBhMDY4NiIsInR5cCI6IkJlYXJlciIsImF6cCI6InRlc3QtY2xpZW50Iiwic2Vzc2lvbl9zdGF0ZSI6IjAzMDQ1MzBkLTYyYjUtNDgzYi05ZTBmLTk4NTNkY2VjNWRiOSIsImFjciI6IjEiLCJyZWFsbV9hY2Nlc3MiOnsicm9sZXMiOlsib2ZmbGluZV9hY2Nlc3MiLCJ1bWFfYXV0aG9yaXphdGlvbiIsImRlZmF1bHQtcm9sZXMtc2FtcGxlcmVhbG0iXX0sInJlc291cmNlX2FjY2VzcyI6eyJhY2NvdW50Ijp7InJvbGVzIjpbIm1hbmFnZS1hY2NvdW50IiwibWFuYWdlLWFjY291bnQtbGlua3MiLCJ2aWV3LXByb2ZpbGUiXX19LCJzY29wZSI6ImVtYWlsIHByb2ZpbGUiLCJlbWFpbF92ZXJpZmllZCI6ZmFsc2UsIm5hbWUiOiJ0YXJvIGNyZWF0aW9ubGluZSIsInByZWZlcnJlZF91c2VybmFtZSI6ImNsLXRhcm8iLCJnaXZlbl9uYW1lIjoidGFybyIsImZhbWlseV9uYW1lIjoiY3JlYXRpb25saW5lIiwiZW1haWwiOiJjcmVhdGlvbmxpbmVAZXhhbXBsZS5jb20ifQ.JEt-YEqNJ5wx343zBB2tz4ImwxPjzLfjsYIW-jrZIkjGcdYB5T_2vEMSNJT8J2Os3wy5MWwF0ZreQM8KTHkBncIDFd6Pt9lpNI5nM1ROmIixmJ9JtSOl9oGrcN2yH2lS9mMIbZg4STlh5ULLywHah9Qm6nO5nWjrCYtPkG-EF7SMvec53_K363lguiqKuN_aqjfdLgvDdEvrAajbQ5ZYwq72-K9xP_frtt1IMeLEONJeLB_xO3sgwmpoCzTUZvuCGXIP9wrpxQ6o0fqFtJyOBWPlNb1YxAvFTyZtlxrdjfWBPp9xcys5a8xfJgr1cG3MuLiaADQOkYnE14wsJEZ9UQ",
    "expires_in": 300,
    "refresh_expires_in": 1800,
    "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICI5YmNlY2RiNC0xZDNjLTQ4MDAtYjdlOS03NjEzYmMwNDVhNzMifQ.eyJleHAiOjE2MjY3MTg5MjgsImlhdCI6MTYyNjcxNzEyOCwianRpIjoiMTU2YmRiOGItZmU4ZS00NjIxLTgzZDAtZTM2ZDRjZWJjYjhmIiwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo4MDg4L2F1dGgvcmVhbG1zL1NhbXBsZVJlYWxtIiwiYXVkIjoiaHR0cDovL2xvY2FsaG9zdDo4MDg4L2F1dGgvcmVhbG1zL1NhbXBsZVJlYWxtIiwic3ViIjoiYzhmODhjOWItMDZhNS00ODA3LWJmMmYtNjEzNWM2MGEwNjg2IiwidHlwIjoiUmVmcmVzaCIsImF6cCI6InRlc3QtY2xpZW50Iiwic2Vzc2lvbl9zdGF0ZSI6IjAzMDQ1MzBkLTYyYjUtNDgzYi05ZTBmLTk4NTNkY2VjNWRiOSIsInNjb3BlIjoiZW1haWwgcHJvZmlsZSJ9.8tllRuyakDap2Ob6IVMbvjLWBqLZel3m7AHoglKtzCc",
    "token_type": "Bearer",
    "not-before-policy": 0,
    "session_state": "0304530d-62b5-483b-9e0f-9853dcec5db9",
    "scope": "email profile"
}