多くのセキュリティ組織の共通目標は、継続的な認証と認可の実装です。Cloudflare Access の JWT 検証を使えば、ユーザー操作を大きく妨げたり、エンドユーザーの行動変容を求めたりせずに、この目標を達成できます。
前のページ で説明したとおり、一部のアプリケーションは、リクエストの認証に直接の SSO 連携を使っています。この種のアプリケーションを Cloudflare の背後に置いてリモートアクセスを有効にすると、ユーザーは 2 回認証する必要があります。まず、Cloudflare Access 経由で ID プロバイダーに認証します。Access への認証が終わると、内部アプリケーションの入口に到達し、直接の SSO 連携で 2 回目の認証を完了する必要があります。
アプリケーション側で 直接の SSO 連携を管理する 代わりに、Cloudflare Access が発行する JSON Web Token（JWT）でリクエストを認証することを推奨します。SSO プロバイダーから返されたトークンの検証は、Cloudflare が主な責任を担います。アプリケーションが Cloudflare JWT を利用するようにすれば、アプリケーションへのアクセスに必要な認証は 1 回だけになり、社内サービスへの認可をより少ない運用負荷で管理できます。
Cloudflare がアプリケーションへリクエストを送ると、そのリクエストにはアカウント固有のキーペアで署名された JWT が含まれます。アプリケーション内に、Cloudflare Access JWT を検証する ワークフローを構築できます。Cloudflare に認証済みのユーザーに対して、HTML ベースの認証より強いセキュリティを提供でき、ログイン体験も途切れません。
認可フローは次の図のとおりです。
アプリケーションに統合 SSO がなく、ジャストインタイム（JIT）のユーザープロビジョニングや管理の手段もない場合、Cloudflare 側でユーザー情報をプライベートアプリケーションへ自動で渡す方法を探すことがよくあります。この目的には、Cloudflare Workers でカスタム HTTP ヘッダーを送る方法が適しています。リクエストが Cloudflare のネットワークを経由してアプリケーションへ届くとき、Worker は Cloudflare Access JWT から取得したユーザー ID、デバイスポスチャ属性、その他のカスタム SAML/OIDC クレームを含むヘッダーをリクエストへ挿入できます。
設定手順は このチュートリアル を参照してください。