web-dev-qa-db-ja.com

Keycloakパブリッククライアントと認証

Keycloakを使用した認証と承認には、Jettyでkeycloak-adapterを使用しています。 OIDC AuthフローのKeycloakドキュメント に従って:

このフローのもう1つの重要な側面は、公開と機密の概念ですクライアント。機密クライアントは、一時コードをトークンと交換するときにクライアントシークレットを提供する必要があります。パブリッククライアントは、このクライアントシークレットを提供する必要はありません。パブリッククライアントは、HTTPSが厳密に適用されており、クライアントに登録されているリダイレクトURIが非常に厳格である限り、完全に問題ありません。

安全な方法でクライアントシークレットをクライアントに送信する方法がないため、HTML5/JavaScriptクライアントは常にパブリッククライアントである必要があります。

Jettyに接続して認証を使用するウェブアプリがあります。そこで、公開クライアントを作成しました。webapp/ REST認証に最適です。
問題は、認証を有効にするとすぐに、クライアントタイプがパブリックからコンフィデンシャルに変換され、パブリックとしてリセットできなくなることです。今、私たちはスープに入っています。承認のためにパブリッククライアントを使用することはできず、webappsを機密クライアントに接続することもできません。
これは私たちに矛盾しているようです。クライアントが承認のために機密である必要がある理由は何ですか?これに関するヘルプはどのようにしてこの問題を克服できますか?
ありがとうございます。

9
NumeroUno

私が理解している限り、フロントエンドとバックエンドのアプリケーションは分離されています。フロントエンドが静的なウェブアプリであり、同じバックエンドアプリケーション(サーバー)によって提供されておらず、バックエンドが単純なREST API-である場合、2つのKeycloakクライアントが構成されます。

  • フロントエンドアプリのpublicクライアント。 JWTトークンの取得を担当します。
  • bearer-onlyクライアント。バックエンドアプリケーションに接続されます。

承認を有効にするには、ロールを作成します(レルムまたはクライアントスコープのいずれかで、理解しやすいレルムレベルから始めます)。すべてのユーザーには、Keycloak管理UIで役割が割り当てられます。これに基づいて、(バックエンドで)keycloakアダプター構成を構成する必要があります。

REST APIと通信するには、Authorizationヘッダーの各HTTPリクエストにJWTトークンを添付する必要があります。フロントエンドフレームワークに応じて、次のいずれかを使用できます。

追伸デバッグのために、JWTトークン(スコープ、ロールなど)をフェッチして分析するのに役立つ brauzie と呼ばれるCLIツールを書いたところです。公共および機密のクライアントの両方に使用できます。 Postman および https://jwt.io を使用することもできます

HTH :)

1
maslick

クライアントを作成するときに、Keycloakの管理コンソールの「Authorization Enabled」スイッチを参照していると思います。ラベルの横にある疑問符にカーソルを合わせると、「クライアントのきめ細かな認証サポートを有効/無効にする」というヒントが表示されます。

Keycloak管理コンソールでクライアントを作成(v 6.0.1)

これは、リソースサーバーとして機能するバックエンドアプリケーションのクライアントを作成する場合を対象としています。その場合、クライアントは機密情報となります。

フロントエンドアプリのクライアントを作成してユーザーを認証し、JWTを取得する場合、これは必要ありません。

参照: https://www.keycloak.org/docs/latest/authorization_services/index.html

0
Arnold Obdeijn

多くの検討の結果、実際に接続するときに、パブリッククライアントで認証を有効にする必要はないことがわかりました。リクエストがパブリッククライアントに届くと、認証部分のみが実行されます。認可部分は、実際のリクエストが機密クライアントを使用してリソースサーバー(この場合はJetty)に到達したときに行われます(Jettyには機密クライアントが構成されていることがわかっているため)。

0
NumeroUno