広告主はよく、サードパーティーのCookieを使用してユーザーの行動を複数のウェブサイトにわたって追跡します。これにより、ユーザーのオンライン活動に関する詳細なプロファイルが構築されます。自覚なく常に監視、把握されるというのは多くのユーザーにとって気持ちの良いことではなく、プライバシーに関する大きな懸念が生じています。サードパーティーのCookieのブロックは、このような追跡を防ぐ手段です。Safariバージョン13.1以降では、
初期状態でサードパーティーのCookieがブロック
されます。その影響で、特定のフローにおいてOktaの機能に支障が出ます。Firefoxおよびその他のブラウザーでも、同様の変更を展開するプロセスが進行中です。Googleの計画については、こちらをご覧ください。
- サードパーティーのCookie
Oktaでホストされているサインインページを使用し、アプリが対象のブラウザーでセッションAPIを呼び出していない場合は、この問題の影響を受けません。お客様が独自のサインイン機能をホストしている場合は、影響を受ける場合があります。
自社でホストしているアプリケーションが、HTTPリクエストに含まれるOktaのセッションCookieを利用してOktaへの呼び出しを実行している場合、Oktaに対して実行されるリクエストはサードパーティーのコンテキストであるため、ブラウザーによってCookieがブロックされてOktaに到達できなくなります。影響を受ける具体的な機能は、セッション管理とOAuth 2.0の暗黙的許可フローおよびPKCEフローにおけるトークン更新です。
どのような影響がありますか。
サードパーティーのCookieをブロックすると、以下のOktaユースケースに影響を及ぼす可能性があります。
お客様が開発したアプリケーションでのセッション管理
サインインページを自社でホストし、自社でホストしているOkta Sign-In Widgetインスタンスを使用している場合、およびセッション管理のために、ユーザーのブラウザーで動作しているJavaScriptを利用してOktaへの呼び出しを実行している場合、ブラウザーによってサードパーティーのCookieがブロックされることが原因で、不具合が生じる恐れがあります。
Okta APIエンドポイント（/sessions/meや/users/me）に対するXHR呼び出しを伴うOktaセッションでは、ユーザーが所在するドメインとは異なる場所にセッションが送信されるため、ブラウザーによってCookieがブロックされます。OktaのセッションCookieがOktaの外に出ることはないため、Oktaはこのリクエストを完了できません。
結果として、Oktaはユーザーに［403 Forbidden（403アクセス禁止）］エラーを返すか、またはアプリケーションがユーザーをサインインページに移動させようとする処理が繰り返されます。
この問題は、Okta Auth JavaScript SDKの特定のメソッドに影響を及ぼします。Okta Sign-In Widgetでは、影響を受けるOkta Auth JavaScript SDKのメソッドを内部的な処理に使用しています。お客様が作成したコードで、OktaセッションAPIに対して直接XHR呼び出しを実行するコードも影響を受けます。詳細については、「Sign-In Widgetによる使用が可能なサードパーティー製Cookie」をご覧ください。
お客様が開発した単ページアプリケーションでの、OAuth 2.0の暗黙的許可フローによるトークン更新
統合でOAuth 2.0の暗黙的許可フローまたはPKCEフローを使用してトークンを更新する場合（通常、暗黙的許可フローまたはPKCEフローを使用するSPAのコンテキストで発生し、リフレッシュトークンは利用していない）、ブラウザーによってOktaのセッションCookieの送信がブロックされるため、トークンの更新が正常に完了することはありません。
その結果、IDトークンとアクセストークンは更新されないまま有効期限が切れてしまい、トークンの有効期間に応じた間隔で、頻繁にサインインを求められます。
Oktaであるページが表示されない場合
たとえば、シークレットモードでSAMLアプリケーションの［設定手順を表示］にアクセスを試みている場合
1つのオプションは、Oktaでカスタムドメインを使用して、ブラウザー側から見てOkta URLとアプリケーションサーバーを効果的に同一ドメインにすることです。これにより、OktaのセッションCookieを当事者のコンテキストに置くことになります。Oktaへの呼び出しは同一サイトからの呼び出しとなり、ブラウザーによるサードパーティーのCookieのブロックが実行されることはなくなります。
たとえば、元となるOkta orgがcompanyname.okta.comというアドレスで、アプリケーションサーバーがapp.companyname.comというアドレスの場合は、カスタムURLドメイン機能によってOkta orgに新しいURL（login.companyname.comなど）を付与することができます。
また、リフレッシュトークンを利用するようにフローを更新することもできます。これにより、ユーザーに再認証を求めることなく、安全なリソースにアクセスするために使用されている現在のトークンを更新することができます。Admin Consoleで、アプリケーションへの「リフレッシュトークン」の付与が有効になっていることを確認し、上記のリンクのサンプルリクエストに従って、アクセストークンを正常に更新するために必要なクエリーパラメーターがあることを確認します。PKCEフローではリフレッシュトークンを利用してトークンの更新を実行できることについても検討してください。
注：ユーザーがカスタムドメインで認証され、必要なCookieを取得できるように、外部のIDプロバイダーもAssertion Consumer Service（ACS）URLを更新して、OktaのSAML IdP構成のURLと一致するようにする必要があります。
関連資料
- Sign-In Widgetによる使用が可能なサードパーティー製Cookie
- Okta開発者向けブログ記事 - 自社でホストしているOkta Sign-in WidgetがサードパーティーCookieなしで動作するように準備する方法
- Google Chromeでのサードパーティー製Cookieの廃止
- Okta開発者向けブログ記事 - サードパーティー製Cookieの終了
- Deprecating 3rd party cookies for Chrome users
- Preparing for the end of third-party cookies
- Okta APIを介したセッションCookie
- 埋め込みSign-in Widgetの展開モデル
- 付与タイプごとの認可の実装
