Red Hat Summit2.4. Red Hat build of Keycloak JavaScript アダプター
Red Hat build of Keycloak には、Web アプリケーションの保護に使用できる、keycloak-js と呼ばれるクライアント側の JavaScript ライブラリーが付属しています。このアダプターには、Cordova アプリケーションのビルトインサポートもあります。
2.4.1. インストール
アダプターはいくつかの方法で配布されますが、NPM から keycloak-js パッケージをインストールすることが推奨されます。
npm install keycloak-js
ライブラリーは、/js/keycloak.js にある Red Hat build of Keycloak サーバーから直接取得することも可能で、さらに ZIP アーカイブとしても配布されます。ただし、Keycloak サーバーから直接アダプターを組み込む方法は非推奨化が検討されており、今後この機能は来削除される可能性があります。
2.4.2. Red Hat build of Keycloak サーバーの設定
クライアント側のアプリケーションの使用に関しては、クライアントの認証情報をクライアント側のアプリケーションに保存する安全な方法がないため、クライアントはパブリッククライアントでなければならない点を考慮する必要があります。これにより、クライアント用に設定したリダイレクト URI が正しく、可能な限り具体的であることを確認することが非常に重要になります。
アダプターを使用するには、Red Hat build of Keycloak 管理コンソールででアプリケーションのクライアントを作成します。Capability config ページで Client authentication を Off に切り替えて、クライアントを公開します。
また、Valid Redirect URI と Web Origins を設定する必要があります。そうしないと、セキュリティーの脆弱性が生じる可能性があるため、できるだけ具体的にしてください。
2.4.3. アダプターの使用
次の例は、アダプターを初期化する方法を示しています。Keycloak コンストラクターに渡されるオプションは、必ず設定したクライアントのオプションに置き換えてください。
import Keycloak from 'keycloak-js';
const keycloak = new Keycloak({
url: 'http://keycloak-server${kc_base_path}',
realm: 'myrealm',
clientId: 'myapp'
});
try {
const authenticated = await keycloak.init();
console.log(`User is ${authenticated ? 'authenticated' : 'not authenticated'}`);
} catch (error) {
console.error('Failed to initialize adapter:', error);
}
認証するには、login 関数を呼び出します。アダプターを自動的に認証する場合、2 つのオプションがあります。、login-required または check-sso を init() 関数に渡せます。
-
login-requiredは、ユーザーが Red Hat build of Keycloak にログインしている場合はクライアントを認証し、ユーザーがログインしていない場合はログインページを表示します。 -
check-ssoは、ユーザーがすでにログインしている場合にのみクライアントを認証します。ユーザーがログインしていない場合、ブラウザーはアプリケーションにリダイレクトされ、認証されないままになります。
silent check-sso オプションを設定できます。この機能を有効にすると、ブラウザーは Red Hat build of Keycloak サーバーの完全なリダイレクトを実行せず、アプリケーションには戻りません。しかし、このこのアクションは非表示の iframe で実行されます。したがって、ブラウザーはアプリケーションの初期化時に一度だけアプリケーションリソースをロードして解析し、Red Hat build of Keycloak からアプリケーションにリダイレクトされた後にこれを再び実行することはありません。このアプローチは、SPA (Single Page Applications) の場合に特に役立ちます。
silent check-sso を有効にするには、init メソッドで silentCheckSsoRedirectUri 属性を指定します。この URI が、アプリケーション内の有効なエンドポイントであることを確認してください。Red Hat build of Keycloak 管理コンソールの有効なリダイレクトとして設定する必要があります。
keycloak.init({
onLoad: 'check-sso',
silentCheckSsoRedirectUri: `${location.origin}/silent-check-sso.html`
});認証の状態が正常にチェックされ、Red Hat build of Keycloak サーバーからトークンを取得すると、サイレント check-sso リダイレクト URI のページが iframe に読み込まれます。受信したトークンをメインアプリケーションに送信する以外のタスクはなく、次のようになります。
<!doctype html>
<html>
<body>
<script>
parent.postMessage(location.href, location.origin);
</script>
</body>
</html>
このページは、アダプターの 一部ではなく、silentCheckSsoRedirectUri の指定された場所にあるアプリケーションによって提供される必要がある点に注意してください。
サイレント check-sso 機能は、一部の最新のブラウザーで制限さていれます。トラッキング防止セクションを実装する最新のブラウザー を参照してください。
login-required を有効にするには、onLoad を login-required に設定し、init メソッドに渡します。
keycloak.init({
onLoad: 'login-required'
});
ユーザーが認証された後、Authorization ヘッダーにベアラートークンを含めることで、アプリケーションは Red Hat build of Keycloak で保護された RESTful サービスへのリクエストを実行できます。以下に例を示します。
async function fetchUsers() {
const response = await fetch('/api/users', {
headers: {
accept: 'application/json',
authorization: `Bearer ${keycloak.token}`
}
});
return response.json();
}
注意すべきことの 1 つは、アクセストークンの有効期限はデフォルトで短いため、リクエストを送信する前にアクセストークンの更新が必要になることが場合があることです。このトークンを更新するには、updateToken() メソッドを呼び出します。このメソッドは、トークンが正常に更新された場合にのみサービスを呼び出し、そうでない場合にはユーザーにエラーを表示することを容易にする Promise を返します。以下に例を示します。
try {
await keycloak.updateToken(30);
} catch (error) {
console.error('Failed to refresh token:', error);
}
const users = await fetchUsers();アクセストークンとリフレッシュトークンは両方ともメモリーに保存され、どの種類のストレージにも永続化されません。したがって、ハイジャック攻撃を防ぐために、これらのトークンは永続化すべきではありません。
2.4.4. セッションステータスの iframe
デフォルトでは、アダプターは、Single-Sign Out が発生したかどうかを検出するために使用される非表示の iframe を作成します。この iframe はネットワークトラフィックを必要としません。代わりに、ステータスは特別なステータス Cookie を参照して取得されます。init() メソッドに渡されるオプションで checkLoginIframe: false を設定すると、この機能を無効化できます。
このクッキーを直接参照する必要はありません。その形式は変更される可能性があり、アプリケーションではなく Red Hat build of Keycloak サーバーの URL にも関連付けられます。
セッションステータスの iframe 機能は、一部の最新のブラウザーで制限されています。トラッキング防止セクションを実装する最新のブラウザー を参照してください。
2.4.5. 暗黙的フローおよびハイブリッドフロー
デフォルトでは、アダプターは 認可コード フローを使用します。
このフローでは、Red Hat build of Keycloak は、認証トークンではなく認可コードをアプリケーションに返します。JavaScript アダプターは、ブラウザーがアプリケーションにリダイレクトされた後に、アクセストークンと更新トークンの コード を交換します。
Red Hat build of Keycloak は、Red Hat build of Keycloak で認証が成功した直後にアクセストークンが送信される Implicit フローもサポートしています。このフローは、コードをトークンと交換する追加のリクエストがないため、標準フローよりもパフォーマンスが向上する可能性がありますが、アクセストークンの有効期限が切れると影響があります。
ただし、URL フラグメントでアクセストークンを送信すると、セキュリティー脆弱性が発生する可能性があります。たとえば、トークンは Web サーバーログやブラウザー履歴によってリークされる可能性があります。
暗黙的フローを有効にするには、Red Hat build of Keycloak 管理コンソールで、クライアントの Implicit Flow Enabled フラグを有効にします。また、パラメーター flow を implicit の値とともに init メソッドに渡します。
keycloak.init({
flow: 'implicit'
})アクセストークンのみが提供され、更新トークンは存在しないことに注意してください。この状況は、アクセストークンの有効期限が切れると、アプリケーションは Red Hat build of Keycloak に再度リダイレクトして、新しいアクセストークンを取得する必要があることを意味します。
Red Hat build of Keycloak は、Hybrid フローもサポートしています。
このフローでは、クライアントは管理コンソールで 標準フロー と 暗黙的フロー の両方を有効にする必要があります。Red Hat build of Keycloak サーバーは、コードとトークンの両方をアプリケーションに送信します。アクセストークンは、コードのアクセスと更新トークンを交換して、すぐに使用できます。暗黙的なフローと同様に、アクセストークンがすぐに利用できるため、ハイブリッドフローはパフォーマンスに適しています。ただし、トークンは URL で依然として送信され、前述のセキュリティーの脆弱性は引き続き適用されます。
Hybrid フローの利点の 1 つは、更新トークンがアプリケーションで利用できることです。
ハイブリッドフローの場合は、パラメーター flow の値 hybrid を init メソッドに渡す必要があります。
keycloak.init({
flow: 'hybrid'
});2.4.6. Cordova でのハイブリッドアプリケーション
Red Hat build of Keycloak は、Apache Cordova で開発されたハイブリッドモバイルアプリをサポートします。アダプターには、cordova と cordova-native という 2 つのモードがあります。
デフォルトは cordova で、アダプタータイプが明示的に設定されておらず、window.cordova が存在する場合、アダプターは自動的にこれを選択します。ログインすると、InApp Browser が開き、ユーザーは Red Hat build of Keycloak と対話できるようになります。その後 http://localhost にリダイレクトしてアプリに戻ります。この動作のために、管理コンソールのクライアント設定セクションで、この URL を有効な redirect-uri としてホワイトリスト化します。
このモードの設定は簡単ですが、いくつかの欠点もあります。
- InApp-Browser はアプリに組み込まれたブラウザーで、電話のデフォルトブラウザーではありません。したがって、設定が異なり、保存されている認証情報は利用できません。
- 特に複雑な内容をレンダリングする場合は、InApp-Browser も遅くなる可能性があります。
- このモードを使用する前に、アプリがログインページをレンダリングするブラウザーを完全に制御できるため、アプリがユーザーの認証情報にアクセスできる可能性があるなど、セキュリティー上の懸念事項を考慮する必要があります。そのため、信頼できないアプリの使用は許可しないでください。
この例のアプリ (https://github.com/keycloak/keycloak/tree/master/examples/cordova) で初めてみましょう。
代替モードは、異なるアプローチをする `cordova-native` です。システムのブラウザーを使用してログインページが開きます。ユーザーが認証されると、ブラウザーは特別な URL を使用してアプリケーションにリダイレクトします。そこから、Red Hat build of Keycloak アダプターは、URL からコードまたはトークンを読み取り、ログインを終了できます。
init() メソッドにアダプター型の cordova-native を渡すことで、ネイティブモードを有効できます。
keycloak.init({
adapter: 'cordova-native'
});このアダプターには 2 つの追加プラグインが必要です。
- cordova-plugin-browsertab: システムのブラウザーで Web ページを開くことができます。
- cordova-plugin-deeplinks: ブラウザーが特別な URL でアプリにリダイレクトできるようにします。
アプリへのリンクの技術情報は、各プラットフォームや特別な設定によって異なります。詳細は、deeplinks プラグインのドキュメント の Android と iOS のセクションを参照してください。
アプリを開くためのリンクにはさまざまな種類があります: * myapp://login または android-app://com.example.myapp/https/example.com/login などのカスタムスキーム * Universal Links (iOS))/Deep Links (Android)。前者はセットアップが簡単で信頼性が高い傾向がありますが、後者は一意であり、ドメインの所有者のみが登録できるため、セキュリティーが強化されます。カスタム URL は iOS で非推奨になりました。最高の信頼性を得るためには、ユニバーサルリンクをカスタム URL リンクを仕様するフォールバックサイトと組み合わせて使用することが推奨されます。
さらに、アダプターとの互換性を改善するには、以下の手順が推奨されます。
-
iOS のユニバーサルリンクは、
response-modeをqueryに設定すると、より確実に動作するようです。 -
リダイレクト時に Android がアプリの新しいインスタンスを開かないようにするには、次のスニペットを
config.xmlに追加します。
<preference name="AndroidLaunchMode" value="singleTask" />
ネイティブモードの使い方を示すアプリの例 (https://github.com/keycloak/keycloak/tree/master/examples/cordova-native) があります。
2.4.7. カスタムアダプター
状況によっては、Capacitor など、デフォルトでサポートされていない環境でアダプターを実行する必要がある場合があります。これらの環境で JavaScript クライアントを使用するには、カスタムアダプターを渡すことができます。たとえば、サードパーティーのライブラリーは、確実に実行できるようにするためのアダプターを提供できます。
import Keycloak from 'keycloak-js';
import KeycloakCapacitorAdapter from 'keycloak-capacitor-adapter';
const keycloak = new Keycloak();
keycloak.init({
adapter: KeycloakCapacitorAdapter,
});この特定のパッケージは存在しませんが、そのようなアダプターをクライアントに渡す方法に関する適切な例を示すことができます。
独自のアダプターを作成することもできます。そのためには、KeycloakAdapter インターフェイスで説明されているメソッドを実装する必要があります。たとえば、以下の TypeScript コードは、すべてのメソッドが適切に実装されていることを確認します。
import Keycloak, { KeycloakAdapter } from 'keycloak-js';
// Implement the 'KeycloakAdapter' interface so that all required methods are guaranteed to be present.
const MyCustomAdapter: KeycloakAdapter = {
login(options) {
// Write your own implementation here.
}
// The other methods go here...
};
const keycloak = new Keycloak();
keycloak.init({
adapter: MyCustomAdapter,
});タイプ情報を省略することで TypeScript を使用せずにこれを実行することもできますが、インターフェイスを確実に適切に実装することは、完全にユーザー次第となります。
2.4.8. 追跡保護機能を備えた最新のブラウザー
一部のブラウザーの最新版では、Chrome の SameSite や完全にブロックされたサードパーティーの cookie など、サードパーティーによるユーザーの追跡を防ぐためにさまざまな cookie ポリシーが適用されています。これらのポリシーは、時間の経過とともにさらに制限が厳しくなり、他のブラウザーでも採用される可能性があります。最終的には、サードパーティーコンテキストの Cookie が完全にサポートされなくなり、ブラウザーによってブロックされる可能性があります。その結果、影響を受けるアダプター機能が、最終的に非推奨になる可能性があります。
アダプターは、セッションステータスの iframe、サイレント check-sso、および部分的に通常の (非サイレント) check-sso についても、サードパーティーの cookie に依存しています。これらの機能は、機能が制限されているか、ブラウザーが cookie に関してどのように制限されているかに基づいて完全に無効になっています。アダプターはこの設定を検出しようとし、それに応じて反応します。
2.4.8.1. SameSite=Lax by Default ポリシーを持つブラウザー
Red Hat build of Keycloak 側およびアプリケーション側で SSL / TLS 接続が設定されている場合、すべての機能がサポートされます。たとえば、Chrome はバージョン 84 以降が影響を受けます。
2.4.8.2. サードパーティーの Cookie がブロックされているブラウザー
セッションステータス iframe はサポートされず、このようなブラウザーの動作がアダプターによって検出されると自動的に無効になります。これは、アダプターは Single Sign-Out 検出にセッション cookie を使用できず、純粋にトークンに依存する必要があることを意味します。その結果、ユーザーが別のウィンドウでログアウトしても、アダプターを使用しているアプリケーションは、アプリケーションがアクセストークンの更新を試行するまでログアウトされません。したがって、ログアウトができるだけ早く検出されるように、アクセストークンの有効期間を比較的短く設定することを検討してください。詳細は、セッションとトークンのタイムアウト を参照してください。
サイレント check-sso はサポートされず、デフォルトで通常の (非サイレント) check-sso にフォールバックします。この動作は、init メソッドに渡されるオプションで、SilentCheckSsoFallback: false を設定することで変更できます。この場合、制限的なブラウザー動作が検出されると、check-sso は完全に無効になります。
通常の check-sso も影響を受けます。セッションステータス iframe がサポートされていないため、アダプターがユーザーのログインステータスをチェックするために初期化される際に、Red Hat build of Keycloak への追加のリダイレクトを行う必要があります。このチェックは、ユーザーがログインしているかどうかを示すために iframe を使用する標準の動作とは異なり、リダイレクトはユーザーがログアウトしている場合にのみ実行されます。
影響を受けるブラウザーは、たとえば、バージョン 13.1 以降の Safari などです。
2.4.9. API リファレンス
2.4.9.1. コンストラクター
new Keycloak();
new Keycloak('http://localhost/keycloak.json');
new Keycloak({ url: 'http://localhost', realm: 'myrealm', clientId: 'myApp' });2.4.9.2. プロパティー
- authenticated
-
ユーザーが認証されている場合は
true、そうでない場合はfalseです。 - token
-
サービスへのリクエストで
Authorizationヘッダーで送ることができる base64 エンコードされたトークン。 - tokenParsed
- 解析されたトークンを JavaScript オブジェクトとして実行します。
- subject
- ユーザー id
- idToken
- base64 でエンコードされた ID トークン。
- idTokenParsed
- 解析された id トークンを JavaScript オブジェクトとして実行します。
- realmAccess
- トークンに関連付けられたレルムロール。
- resourceAccess
- トークンに関連付けられたリソースロール。
- refreshToken
- 新しいトークンの取得に使用できる base64 でエンコードされた更新トークン。
- refreshTokenParsed
- JavaScript オブジェクトとして解析された更新トークン。
- timeSkew
- ブラウザー時間と Red Hat build of Keycloak サーバー間の推定時間差 (秒単位)。この値は見積りませんが、トークンの有効期限が切れているかどうかを判断します。
- responseMode
- init で渡される応答モード (デフォルト値は fragment)。
- flow
- init に渡されるフロー。
- adapter
リダイレクトする方法と、その他のブラウザー関連の機能がライブラリーによって処理される方法を上書きできます。利用可能なオプション:
- default - ライブラリーはリダイレクトにブラウザー api を使用します (これがデフォルトです)。
- cordova - ライブラリーは InAppBrowser cordova プラグインを使用して keycloak login/registration ページを読み込もうとします (これは、ライブラリーが cordova エコシステムで作業しているときに自動的に使用されます)。
- cordova-native - ライブラリーは、BrowserTabs cordova プラグインを使用して、電話のシステムブラウザーを使用してログインおよび登録ページを開くことを試みます。これには、アプリにリダイレクトするための特別な設定が必要です (「Cordova でのハイブリッドアプリケーション」 を参照)。
- custom - カスタムアダプターを実装することができます (高度なユースケースのみ)。
- responseType
- ログインリクエストとともに Red Hat build of Keycloak に送信されるレスポンスタイプ。これは初期化時に使用されるフロー値に基づいて決定されますが、この値を設定すると上書きできます。
2.4.9.3. メソッド
init(options)
アダプターを初期化するために呼び出されます。
オプションはオブジェクトです。ここでは、以下のようになります。
-
useNonce - 暗号化ナンスを追加して、認証応答がリクエストと一致することを確認します (デフォルトは
true)。 -
onLoad - 読み込み時に実行するアクションを指定します。サポートされている値は、
login-requiredまたはcheck-ssoです。 - silentCheckSsoRedirectUri - onLoad が check-sso に設定されたかどうかをサイレント認証チェックにリダイレクト URI を設定します。
-
silentCheckSsoFallback: サイレント
check-ssoがブラウザーでサポートされない場合に、通常のcheck-ssoへのフォールバックを有効にします (デフォルトはtrue)。 - token - トークンに初期値を設定します。
- refreshToken - 更新トークンの初期値を設定します。
- idToken - id トークンに初期値を設定します (トークンまたは refreshToken とともにのみ)。
-
scope - デフォルトのスコープパラメーターを Red Hat build of Keycloak ログインエンドポイントに設定します。スコープのスペースで区切られたリストを使用します。これらは通常、特定のクライアントで定義された クライアントスコープ を参照します。スコープの
openidは、アダプターによって常にスコープのリストに追加されることに注意してください。たとえば、スコープオプションのaddress phoneを入力すると、Red Hat build of Keycloak へのリクエストにはスコープパラメーターscope=openid address phoneが含まれます。login()オプションでスコープを明示的に指定すると、ここで指定したデフォルトのスコープが上書きされることに注意してください。 - timeSkew - ローカルタイムと Red Hat build of Keycloak サーバー間のスキュー用に初期値を設定します (トークンと refreshToken の場合のみ)。
-
checkLoginIframe - ログイン状態の監視を有効にするかどうかを設定します (デフォルト値は
true)。 - checkLoginIframeInterval - ログイン状態を確認する間隔を設定します (デフォルトは 5 秒です)。
-
responseMode - ログイン要求時に OpenID Connect 応答モードを Red Hat build of Keycloak サーバーに送信します。有効な値は
queryまたはfragmentです。デフォルト値はfragmentで、認証に成功した後、OpenID Connect パラメーターを URL フラグメントに追加した JavaScript アプリケーションに Red Hat build of Keycloak がリダイレクトすることを意味します。これは一般的には、より安全で、queryを介して推奨されています。 -
flow - OpenID Connect フローを設定します。有効な値は、
standard、implicit、またはhybridです。 -
enableLogging - Keycloak からコンソールへのログメッセージを有効にします (デフォルトは
falseです)。 pkceMethod - 使用する Proof Key Code Exchange (PKCE) のメソッド。この値を設定すると、PKCE メカニズムが有効になります。利用可能なオプション:
- S256 - SHA256 ベースの PKCE メソッド
-
scope - スコープパラメーターを Red Hat build of Keycloak ログインエンドポイントに転送するために使用されます。スコープのスペースで区切られたリストを使用します。これらは通常、特定のクライアントで定義された クライアントスコープ を参照します。スコープの
openidは、アダプターによって常にスコープのリストに追加されることに注意してください。たとえば、スコープオプションのaddress phoneを入力すると、Red Hat build of Keycloak へのリクエストにはスコープパラメーターscope=openid address phoneが含まれます。 - messageReceiveTimeout: Keycloak サーバーからのメッセージ応答を待つタイムアウトをミリ秒単位で設定します。これは、たとえば、サードパーティーの Cookie チェック中に、メッセージを待機するときに使用されます。デフォルト値は 10000 です。
- locale - onLoad が 'login-required' の場合、OIDC 1.0 仕様のセクション 3.1.2.1 に従って 'ui_locales' クエリーパラメーターを設定します。
初期化の完了時に解決する promise を返します。
login(options)
ログインフォームにリダイレクトします。
options は任意のオブジェクトです。ここでは、以下のようになります。
- redirecturi - ログイン後にリダイレクトする URI を指定します。
-
prompt - Red Hat build of Keycloak サーバー側でログインフローを若干カスタマイズできるようにします。たとえば、値の
loginの場合、ログイン画面の表示を強制します。promptパラメーターの詳細および使用できるすべての値については、パラメーター転送 セクションを参照してください。 -
maxAge - ユーザーがすでに認証されている場合にのみ使用します。ユーザーの認証が発生した時点の最大時間を指定します。ユーザーが
maxAgeよりも長い期間認証されている場合、SSO は無視されるため、再認証が必要になります。 - loginHint - ログインフォームの username/email フィールドを事前に入力するのに使用されます。
-
scope -
initで設定されたスコープを、この特定ログインの別の値でオーバーライドします。 - idpHint - Red Hat build of Keycloak に対して、ログインページの表示を省略し、代わりに指定されたアイデンティティープロバイダーに自動的にリダイレクトするように指示するために使用されます。詳細は、アイデンティティープロバイダーのドキュメント を参照してください。
-
acr:
acr要求についての情報が含まれます。これは、claimsパラメーター内で Red Hat build of Keycloak サーバーに送信されます。一般的な用途は、段階的な認証です。使用例:{ values: ["silver", "gold"], essential: true }詳細は、OpenID Connect の仕様および ステップアップ認証のドキュメント を参照してください。 -
action - 値が
registerの場合、ユーザーは登録ページにリダイレクトされます。詳細は、クライアントによって要求された登録 セクションを参照してください。値がUPDATE_PASSWORDまたはサポートされている別の必須アクションの場合、ユーザーはパスワードのリセットページまたはその他の必須アクションページにリダイレクトされます。ただし、ユーザーが認証されていない場合は、ユーザーはログインページへ移動され、認証後にリダイレクトされます。詳細は、アプリケーションが開始したアクションセクション を参照してください。 - locale - OIDC 1.0 仕様のセクション 3.1.2.1 に従って、ui_locales クエリーパラメーターを設定します。
-
cordovaOptions - Cordova in-app-browser (該当する場合) に渡される引数を指定します。
hiddenオプションおよびlocationオプションは、これらの引数の影響を受けません。利用可能なすべてのオプションは https://cordova.apache.org/docs/en/latest/reference/cordova-plugin-inappbrowser/ で定義されています。使用例:{ zoom: "no", hardwareback: "yes" };
createLoginUrl(options)
ログインフォームへの URL を返します。
options は任意のオブジェクトで、関数 login と同じオプションをサポートします。
logout(options)
ログアウトにリダイレクトされます。
オプションはオブジェクトです。ここでは、以下のようになります。
- redirectUri - ログアウト後にリダイレクトする URI を指定します。
createLogoutUrl(options)
ユーザーをログアウトするための URL を返します。
オプションはオブジェクトです。ここでは、以下のようになります。
- redirectUri - ログアウト後にリダイレクトする URI を指定します。
register(options)
登録フォームにリダイレクトされます。オプション action = 'register' を使用したログインのショートカット
オプションはログイン方法と同じですが、action は register に設定されています
createRegisterUrl(options)
登録ページへの URL を返します。オプション action = 'register' を持つ createLoginUrl のショートカット
オプションは createLoginUrl メソッドと同じですが、action は register に設定されています
accountManagement()
アカウント管理コンソールにリダイレクトされます。
createAccountUrl(options)
アカウント管理コンソールに URL を返します。
オプションはオブジェクトです。ここでは、以下のようになります。
- redirectUri: アプリケーションにリダイレクトする際にリダイレクトする URI を指定します。
hasRealmRole(role)
トークンに指定のレルムロールがある場合は true を返します。
hasResourceRole(role, resource)
トークンにリソースの指定されたロールがある場合に true を返します (指定の clientId が使用されていない場合、リソースは任意です)。
loadUserProfile()
ユーザープロファイルを読み込みます。
プロファイルで解決する promise を返します。
以下に例を示します。
try {
const profile = await keycloak.loadUserProfile();
console.log('Retrieved user profile:', profile);
} catch (error) {
console.error('Failed to load user profile:', error);
}isTokenExpired(minValidity)
トークンの有効期限が切れる前にトークンが minValidity 秒未満の場合は true を返します (minValidity は任意であり、指定されていない場合は 0 が使用されます)。
updateToken(minValidity)
トークンが minValidity 秒以内に期限切れになると (minValidity は任意で、指定されていない場合は 5 が使用されます)、トークンが更新されます。-1 が minValidity として渡された場合、トークンは強制的に更新されます。セッションステータスが iframe が有効になっている場合は、セッションステータスもチェックされます。
トークンが更新されているかどうかを示すブール値で解決する promise を返します。
以下に例を示します。
try {
const refreshed = await keycloak.updateToken(5);
console.log(refreshed ? 'Token was refreshed' : 'Token is still valid');
} catch (error) {
console.error('Failed to refresh the token:', error);
}clearToken()
トークンを含む認証状態を消去します。これは、トークンの更新が失敗した場合など、セッションの期限が切れたことをアプリケーションが検出する場合に役立ちます。
これを呼び出すと、AuthLogout コールバックリスナーが呼び出されます。
2.4.9.4. コールバックイベント
アダプターは、特定のイベントの callback リスナーの設定をサポートします。これらは init() メソッドを呼び出す前に設定する必要があることに注意してください。
以下に例を示します。
keycloak.onAuthSuccess = () => console.log('Authenticated!');利用可能なイベントは以下のとおりです。
- onReady(authenticated) - アダプターが初期化されると呼び出されます。
- onAuthSuccess - ユーザーが正常に認証されると呼び出しされます。
- onAuthError - 認証中にエラーが発生した場合に呼び出しされます。
- onAuthRefreshSuccess - トークンの更新時に呼び出しされます。
- onAuthRefreshError - トークンの更新中にエラーが発生した場合に呼び出します。
- onAuthLogout - ユーザーがログアウトした場合に呼び出されます (セッションステータス iframe が有効になっている場合、または Cordova モードの場合にのみ呼び出されます)。
- onTokenExpired - アクセストークンの期限が切れたときに呼び出しされます。更新トークンが利用可能な場合、トークンは updateToken で更新できます。利用できない場合 (つまり暗黙的なフローの場合) は、ログイン画面にリダイレクトして新しいアクセストークンを取得できます。
