Chrome 126 以降、デベロッパーは次のバンドルのオリジン トライアルを開始できます。 デスクトップの Federated Credential Management API(FedCM)機能を使用して、 認可のユースケース。このバンドルは Continuation API と Parameters API。OAuth 認証フローに似たエクスペリエンスを実現します。 ID プロバイダ(IdP)提供の権限ダイアログを含む。このバンドルには Fields API、複数の configURLs、Custom など、 アカウントのラベルChrome 126 以降、 Storage Access API(SAA): ユーザーが 以前に FedCM を使用して正常にログインできたかどうか。
オリジン トライアル: FedCM Continuation API バンドル
FedCM Continuation API バンドルは、複数の FedCM 拡張機能で構成されています。
Continuation API
<ph type="x-smartling-placeholder">Glitch で API を使用するデモをご覧いただけます。
Continuation API を使用すると、 IdP の ID アサーション エンドポイント管理 必要に応じて FedCM がレンダリングする URL を返し、ユーザーが続けて 構成されます。これにより、IdP はユーザーに権限を許可するよう 既存の FedCM UI で可能な以上の証明書利用者(RP)権限 ユーザーのサーバーサイド リソースへのアクセスなど、
通常、ID アサーション エンドポイントは、必要なトークンを あります。
{
"token": "***********"
}
これに対して Continuation API では、
エンドポイントが
絶対パスまたは相対パスを含む continue_on
プロパティを返す
ID アサーション エンドポイントへのパスを指定します。
{
// In the id_assertion_endpoint, instead of returning a typical
// "token" response, the IdP decides that it needs the user to
// continue on a pop-up window:
"continue_on": "/oauth/authorize?scope=..."
}
ブラウザが continue_on
レスポンスを受信するとすぐに、新しいポップアップ ウィンドウが表示されます。
が開き、指定されたパスにユーザーを誘導します。
ユーザーがページを操作した後(追加の権限を付与するなど)
追加情報を RP と共有すると、IdP ページから
IdentityProvider.resolve()
: 元の
navigator.credentials.get()
を呼び出して、引数としてトークンを返します。
document.getElementById('allow_btn').addEventListener('click', async () => {
let accessToken = await fetch('/generate_access_token.cgi');
// Closes the window and resolves the promise (that is still hanging
// in the relying party's renderer) with the value that is passed.
IdentityProvider.resolve(accessToken);
});
その後、ブラウザはポップアップを自ら閉じ、API にトークンを返します。 呼び出します。
ユーザーがリクエストを拒否した場合は、
IdentityProvider.close()
。
IdentityProvider.close();
なんらかの理由でユーザーがポップアップでアカウントを変更した場合( IdP が「ユーザーの切り替え」委任のケースでは、この解決は call はオプションの 2 番目の引数を取り、次のようなものです。
IdentityProvider.resolve(token, {accountId: '1234');
パラメータ API
Parameters API を使用すると、RP 追加のパラメータを ID アサーションに提供 提供します。 Parameters API を使用すると、RP は追加のパラメータを IdP に渡して、 基本的なログイン以外のリソースに対する権限をリクエストします。この場合、ユーザーは IdP 制御の UX フローを介してこれらの権限にアクセスできます。このフローは Continuation API。
API を使用するには、パラメータをオブジェクトとして params
プロパティに追加します。
navigator.credentials.get()
の呼び出し。
let {token} = await navigator.credentials.get({
identity: {
providers: [{
clientId: '1234',
configURL: 'https://idp.example/fedcm.json',
// Key/value pairs that need to be passed from the
// RP to the IdP but that don't really play any role with
// the browser.
params: {
IDP_SPECIFIC_PARAM: '1',
foo: 'BAR',
ETC: 'MOAR',
scope: 'calendar.readonly photos.write',
}
},
}
});
params
オブジェクトのプロパティ名の先頭には param_
が付加されます。
上記の例で、params プロパティには IDP_SPECIFIC_PARAM
が '1'
、foo
として含まれています。
'BAR'
、ETC
'MOAR'
、scope
と 'calendar.readonly photos.write'
の形式を使用します。
これは次のように翻訳されます。
param_IDP_SPECIFIC_PARAM=1¶m_foo=BAR¶m_ETC=MOAR¶m_scope=calendar.readonly%20photos.write
を、リクエストの HTTP 本文内に挿入します。
POST /fedcm_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false¶m_IDP_SPECIFIC_PARAM=1¶m_foo=BAR¶m_ETC=MOAR¶m_scope=calendar.readonly%20photos.write
権限を動的に取得する
一般に、ユーザーにとっては、権限のリクエストは 開発者が簡単に実装できると考えているのではありません。対象 たとえば、ユーザーが撮影しようとしたときにカメラへのアクセス許可を求めるなどです。 ユーザーがウェブサイトにアクセスしたらすぐに許可を求めるよりも、 確認できますサーバー リソースについても同じことが言えます。権限をリクエストするだけ ユーザーが必要とするときに通知されます。これは「動的承認」と呼ばれます。
FedCM を使用して動的に認可をリクエストするには、IdP で次の操作を行うことができます。
- IdP がアクセスできる必須パラメータを使用して
navigator.credentials.get()
を呼び出す 使用できます(scope
など)。 - ID アサーション
エンドポイント
ユーザーがすでにログインしていることを確認し、
continue_on
URL を返します。 - ブラウザでポップアップ ウィンドウが開き、IdP の権限ページが リクエストされたスコープに一致する追加の権限。
- IdP によって
IdentityProvider.resolve()
経由で承認されると、ウィンドウは次のようになります。 閉じられ、RP の元のnavigator.credentials.get()
呼び出しが トークンまたは認証コードを RP がトークンまたは認証コードを 付与する必要があります。
フィールド API
Fields API を使用すると、RP で以下を行うことができます。 IdP にリクエストするアカウント属性を宣言し、ブラウザが FedCM ダイアログに適切な開示 UI を表示するそれは IdP の責任で 返されたトークンにリクエストされたフィールドを含めます。このリクエストについて 「基本的なプロフィール」OpenID Connect と「スコープ」の違い説明します。
<ph type="x-smartling-placeholder">で確認できます。 <ph type="x-smartling-placeholder">Fields API を使用するには、パラメータを配列として fields
プロパティに追加します。
navigator.credentials.get()
の呼び出し。フィールドには 'name'
、'email'
を含めることができます。
今のところは 'picture'
ですが、これを拡張してより多くの値を含めることもできます。
説明します。
fields
を使用したリクエストは次のようになります。
let { token } = await navigator.credentials.get({
identity: {
providers: [{
fields: ['name', 'email', 'picture'],
clientId: '1234',
configURL: 'https://idp.example/fedcm.json',
params: {
scope: 'drive.readonly calendar.readonly',
}
},
}
mediation: 'optional',
});
ID アサーションに対する HTTP リクエスト
エンドポイント
RP で指定された fields
パラメータを disclosure_text_shown
とともに含める
このパラメータは、リピーターでない場合は true
に設定され、
disclosure_shown_for
パラメータでユーザーに開示するブラウザ:
POST /id_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=true&fields=email,name,picture&disclosure_shown_for=email,name,picture
IdP からの追加データに RP がアクセスする必要がある場合(たとえば、
これは、前述のカスタム パラメータを使って処理する必要があります。「
IdP は continue_on
URL を返して権限をリクエストします。
fields
が空の配列の場合、リクエストは次のようになります。
let { token } = await navigator.credentials.get({
identity: {
providers: [{
fields: [],
clientId: '1234',
configURL: 'https://idp.example/fedcm.json',
params: {
scope: 'drive.readonly calendar.readonly',
}
},
}
mediation: 'optional',
});
fields
に空の配列を指定した場合、ユーザー エージェントは開示 UI をスキップします。
これは、アカウントからのレスポンスが
エンドポイント
approved_clients
の RP と一致するクライアント ID が含まれていない。
この例では、ID アサーションに送信された disclosure_text_shown
が ID アサーションです。
endpoint です。
false に設定します。
POST /id_assertion_endpoint HTTP/1.1
Host: idp.example
Origin: https://rp.example/
Content-Type: application/x-www-form-urlencoded
Cookie: 0x23223
Sec-Fetch-Dest: webidentity
account_id=123&client_id=client1234&nonce=234234&disclosure_text_shown=false
複数の configURL
複数の configURL で IdP を許可する
複数の構成ファイルに対応するように構成するには、
accounts_endpoint
と login_url
を、
ファイルを
指定します。
accounts_endpoint
と login_url
が well-known ファイルに追加されると、
provider_urls
は無視されるため、IdP は複数の構成ファイルをサポートできます。
一致していない場合、provider_urls
は引き続き有効になり、元の値に戻ります。
対応しています。
複数の configURL をサポートする広く知られたファイルは、次のようになります。
{
"provider_urls": [ "https://idp.example/fedcm.json" ],
"accounts_endpoint": "https://idp.example/accounts",
"login_url": "https://idp.example/login"
}
このため、次のことを実現できる。
- 既存のよく知られたファイルとの後方互換性および前方互換性を維持 すでに導入されている旧バージョンのブラウザにも対応します。
- 任意の数の構成ファイルを使用できます。ただし、すべての構成ファイルが
同じ
accounts_endpoint
とlogin_url
。 - 認証情報を取得する取得リクエストにエントロピーを追加する機会がない
accounts_endpoint
に設定されていなければなりません。これは、 「.well-known」できます。
複数の configURL のサポートは任意で、既存の FedCM では 同じ実装が可能です。
カスタム アカウント ラベル
カスタム アカウント ラベルにより FedCM が可能
IdP がアカウントにアノテーションを付けることにより、RP が
記述できます。Domain Hints を使用しても、同様のフィルタリングが可能です。
API とログイン
Hint API を使用します。
navigator.credentials.get()
呼び出しでも使用できますが、カスタム アカウント ラベルは
構成ファイルを指定してユーザーをフィルタできます。これは、
複数の configURL が使用されている。カスタムアカウントラベルは
IdP サーバーから提供されるのではなく、IdP サーバーから提供されるという点でも異なります。
ログインやドメインヒントなどです。
例
IdP は、コンシューマ用とエンタープライズ用にそれぞれ 2 つの configURL をサポートしています。「
コンシューマ構成ファイルに 'consumer'
ラベルがあり、エンタープライズ構成ファイルに
'enterprise'
ラベルがある。
このような設定では、well-known ファイルに accounts_endpoint
と
login_url
: 複数の configURL を許可します。
{
"provider_urls": [ "https://idp.example/fedcm.json" ],
"accounts_endpoint": "https://idp.example/accounts",
"login_url": "https://idp.example/login"
}
accounts_endpoint
が well-known ファイルで指定されている場合、
provider_urls
は無視されます。RP はそれぞれの構成を直接参照できる
navigator.credentials.get()
呼び出しで参照できます。
コンシューマの構成ファイルは https://idp.example/fedcm.json
にあります。これには次のものが含まれます。
include
を使用して 'consumer'
を指定する accounts
プロパティ。
{
"accounts_endpoint": "https://idp.example/accounts",
"client_metadata_endpoint": "/client_metadata",
"login_url": "https://idp.example/login",
"id_assertion_endpoint": "/assertion",
"accounts": {
"include": "consumer"
}
}
エンタープライズ構成ファイルは https://idp.example/enterprise/fedcm.json
にあります。
これには、'enterprise'
を指定する accounts
プロパティが含まれており、
include
。
{
"accounts_endpoint": "https://idp.example/accounts",
"client_metadata_endpoint": "/enterprise/client_metadata",
"login_url": "https://idp.example/login",
"id_assertion_endpoint": "/assertion",
"accounts": {
"include": "enterprise"
}
}
共通の IdP アカウント
エンドポイント
(この例では https://idp.example/accounts
)は、
各アカウントの配列に labels
が割り当てられた labels プロパティが含まれている。
以下は、2 つのアカウントを持つユーザーに対するレスポンスの例です。1 つは
2 種類に分かれます
{
"accounts": [{
"id": "123",
"given_name": "John",
"name": "John Doe",
"email": "john_doe@idp.example",
"picture": "https://idp.example/profile/123",
"labels": ["consumer"]
}], [{
"id": "4567",
"given_name": "Jane",
"name": "Jane Doe",
"email": "jane_doe@idp.example",
"picture": "https://idp.example/profile/4567",
"labels": ["enterprise"]
}]
}
RP が 'enterprise'
人のユーザーにログインを許可する場合、ユーザーは
'enterprise'
の configURL 'https://idp.example/enterprise/fedcm.json'
に
navigator.credentials.get()
呼び出し:
let { token } = await navigator.credentials.get({
identity: {
providers: [{
clientId: '1234',
nonce: '234234',
configURL: 'https://idp.example/enterprise/fedcm.json',
},
}
});
そのため、ユーザーが署名に使用できるアカウント ID は '4567'
のみです。
できます。アカウント ID '123'
はブラウザによって通知なく非表示になるため、ユーザーは
には、このサイトの IdP でサポートされていないアカウントは取得されません。
オリジン トライアル: Storage Access API のトラスト シグナルとしての FedCM
Chrome 126 では、 ストレージへのアクセス API。あり FedCM を介した事前のアクセス許可の付与は、 リクエストによって、ストレージ アクセス リクエストが自動的に承認され、 API。
これは、埋め込み iframe がパーソナライズされたリソースにアクセスする必要がある場合に役立ちます。 たとえば、idp.example が rp.example に埋め込まれていて、 確認しましょう。ブラウザでサードパーティ Cookie へのアクセスが 制限されている場合 ユーザーが FedCM の idp.example を使用して rp.example にログインしていても、 埋め込みの idp.example iframe は、パーソナライズされたリソースをリクエストできない リクエストにサードパーティの Cookie が含まれていないためです。
これを実現するには、idp.example は iframe が埋め込まれています。この URL は、 プロンプトが表示されます。
ストレージ アクセスのためのトラスト シグナルとして FedCM を使用 API Storage Access API の権限チェックでは、権限の付与を承認するだけでなく、 権限の付与だけでなく、ストレージ アクセスのプロンプト FedCM プロンプト。
// In top-level rp.example:
// Ensure FedCM permission has been granted.
const cred = await navigator.credentials.get({
identity: {
providers: [{
configURL: 'https://idp.example/fedcm.json',
clientId: '123',
}],
},
mediation: 'optional',
});
// In an embedded IdP iframe:
// No user gesture is needed to call this, and the call will be auto-granted.
await document.requestStorageAccess();
// This returns `true`.
const hasAccess = await document.hasStorageAccess();
ユーザーが FedCM でログインすると、次の期間、権限が自動的に付与されます。 FedCM 認証が有効になっていることを確認します。つまり、ユーザーの接続が切断されると、 プロンプトが表示されます。
オリジン トライアルに参加する
FedCM Continuation API バンドルをローカルで試すには、Chrome
フラグ
chrome://flags#fedcm-authz
(Chrome 126 以降)。FedCM
Storage Access API のトラスト シグナルとしてローカルに許可する場合は、
#fedcm-with-storage-access-api
(Chrome 126 以降)。
これらの機能はオリジン トライアルとしても利用できます。オリジン トライアルでは、新機能を試して、ユーザビリティ、実用性、有効性に関するフィードバックを提供できます。詳しくは、オリジン トライアルのスタートガイドをご覧ください。
FedCM Continuation API バンドルのオリジンを試すには 試用 次の 2 つのオリジン トライアル トークンを作成します。
- トライアルに登録します。トークンを IdP に埋め込む origin を指定します。
- [サードパーティの照合] チェックボックスをオンにしてオリジン トライアルに登録する。 の手順に沿って、サードパーティのオリジン トライアルを RP: RP のトークンを埋め込む場合。
ボタンとともに Continuation API を有効にする場合 フローで [ボタンモード] を有効にします。 API オリジン トライアル さらに:
- サードパーティとしてオリジン トライアルに登録する。以下の手順に従います。 RP にサードパーティのオリジン トライアルを登録して埋め込む 使用します。
Storage Access API オリジンのトラスト シグナルとして FedCM を試す 試用版:
- オリジン トライアルに登録します。トークンを IdP に埋め込む origin を指定します。
Continuation API バンドルのオリジン トライアルと FedCM を、 Storage Access API のオリジン トライアルは Chrome 126 から利用できます。
RP にサードパーティのオリジン トライアルを登録する
- オリジン トライアルの登録ページに移動します。
- [Register] ボタンをクリックし、フォームに記入してトークンをリクエストします。
- IdP の生成元を [ウェブ生成元] として入力します。
- 他のオリジンで JavaScript を使用してトークンを挿入する場合は、[サードパーティ マッチング] チェックボックスをオンにします。
- [送信] をクリックします。
- 発行されたトークンをサードパーティのウェブサイトに埋め込みます。
トークンをサードパーティのウェブサイトに埋め込むには、IdP の IdP のオリジンから提供される JavaScript ライブラリまたは SDK。
const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);
TOKEN_GOES_HERE
は、独自のトークンに置き換えます。