Questa pagina è stata tradotta dall'API Cloud Translation.

Aggiornamenti di FedCM: prove dell'origine per il bundle dell'API Continuation e concessione automatica dell'API Storage Access

Eiji Kitamura

A partire da Chrome 126, gli sviluppatori possono iniziare a eseguire una prova dell'origine per un bundle di le funzionalità dell'API desktop Federated Credential Management (FedCM) che abilitano Casi d'uso relativi all'autorizzazione. Il bundle è composto dall'API Continuation e API Parameters, che consentono un'esperienza simile al flusso di autorizzazione OAuth che coinvolga una finestra di dialogo dell'autorizzazione fornita da un provider di identità (IdP). Il cofanetto inoltre include altre modifiche, ad esempio API Fields, Più configURL e Custom Etichette dell'account. A partire da Chrome 126, stiamo introducendo anche una prova dell'origine per API Storage Access (SAA) che concede automaticamente le richieste SAA se l'utente ha ha eseguito correttamente l'accesso utilizzando FedCM in passato.

Prova dell'origine: bundle dell'API FedCM Continuation

Il bundle dell'API FedCM Continuation è composto da più estensioni FedCM:

API Continuation
API Parameters
API Field
Più configURL
Etichette dell'account personalizzate

API Continuation

Un utente sta eseguendo l'accesso alla parte soggetta a limitazioni e poi autorizza tramite la modalità a pulsante.

Puoi guardare una demo dell'API su Glitch.

L'API Continuation consente Asserzione ID dell'IdP su facoltativamente, restituiscono un URL che verrà visualizzato da FedCM per consentire all'utente di continuare un flusso di accesso in più passaggi. Ciò consente all'IdP di richiedere all'utente di concedere basare le autorizzazioni di parte (RP) al di là di quanto possibile nell'interfaccia utente FedCM esistente, come l'accesso alle risorse lato server dell'utente.

Di solito, l'endpoint di asserzione dell'ID restituisce un token necessario per: autenticazione.

{
  "token": "***********"
}

Con l'API Continuation, invece, l'asserzione ID endpoint può restituiscono una proprietà continue_on che include un percorso assoluto o un relativo all'endpoint di asserzione 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=..."
}

Non appena il browser riceve la risposta continue_on, viene visualizzata una nuova finestra popup viene aperto e l'utente viene indirizzato al percorso specificato.

Dopo che l'utente ha interagito con la pagina, ad esempio concedendo ulteriori autorizzazioni. per condividere informazioni aggiuntive con la parte soggetta a limitazioni, la pagina dell'IdP può chiamare IdentityProvider.resolve() per risolvere l'originale navigator.credentials.get() e restituisce un token come argomento.

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);
});

Il browser chiuderà il popup da solo e restituirà il token all'API chiamante.

Se l'utente rifiuta la richiesta, puoi chiudere la finestra chiamando IdentityProvider.close().

IdentityProvider.close();

Se per qualche motivo l'utente ha cambiato l'account nel popup (ad esempio l'IdP offre la possibilità di cambiare utente o nei casi di delega), la risoluzione prende un secondo argomento facoltativo che consente, ad esempio:

IdentityProvider.resolve(token, {accountId: '1234');

API Parameters

L'API Parameters consente alla parte soggetta a limitazioni per fornire parametri aggiuntivi all'asserzione ID endpoint. Con l'API Parameters, le parti soggette a limitazioni possono passare parametri aggiuntivi all'IdP per richiedere autorizzazioni per risorse oltre all'accesso di base. L'utente autorizzerebbe queste autorizzazioni tramite un flusso UX controllato dall'IdP che viene avviato tramite API Continuation.

Per utilizzare l'API, aggiungi parametri alla proprietà params come oggetto nel Chiamata 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',
      }
    },
  }
});

I nomi delle proprietà nell'oggetto params sono preceduti da param_. Nella nell'esempio riportato sopra, la proprietà params contiene IDP_SPECIFIC_PARAM come '1', foo come 'BAR', ETC come 'MOAR' e scope come 'calendar.readonly photos.write'. Verrà tradotto come param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write nel corpo HTTP della richiesta:

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&param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write

Ottieni le autorizzazioni in modo dinamico

In generale, per gli utenti è più utile richiedere le autorizzazioni quando necessarie, piuttosto che quando lo sviluppatore ritiene che siano più facili da implementare. Per Ad esempio, chiedere l'autorizzazione ad accedere a una fotocamera mentre l'utente sta per scattare è preferibile chiedere l'autorizzazione alle foto non appena l'utente arriva sul sito web. Lo stesso vale per le risorse server. Richiedi solo autorizzazioni quando sono necessarie per l'utente. Questa si chiama "autorizzazione dinamica".

Per richiedere l'autorizzazione in modo dinamico con FedCM, l'IdP può:

Chiama navigator.credentials.get() con i parametri richiesti che l'IdP può comprendere, ad esempio scope.
L'asserzione ID endpoint Conferma che l'utente ha già eseguito l'accesso e risponde con un URL continue_on.
Il browser apre una finestra popup con la pagina delle autorizzazioni dell'IdP in cui viene richiesta la un'altra autorizzazione che corrisponde agli ambiti richiesti.
Dopo aver autorizzato l'IdP mediante IdentityProvider.resolve(), la finestra viene chiusa e la chiamata navigator.credentials.get() originale della parte soggetta a limitazioni riceve un pertinente o un codice di autorizzazione in modo che la parte soggetta a limitazioni possa scambiarlo il token di accesso corretto.

API Fields

L'API Field consente alla parte soggetta a limitazioni di dichiarare gli attributi dell'account da richiedere all'IdP affinché il browser possa mostrare un'interfaccia utente per l'informativa corretta nella finestra di dialogo FedCM; è responsabilità dell'IdP per includere i campi richiesti nel token restituito. Considera questa richiesta un "profilo di base" in OpenID Connect e negli "ambiti" in OAuth.

Messaggio di divulgazione in modalità widget.

di Gemini Advanced.

Messaggio informativo in modalità pulsante.

Per utilizzare l'API Fields, aggiungi parametri alla proprietà fields come array nella Chiamata navigator.credentials.get(). I campi possono contenere 'name', 'email' e 'picture' per ora, ma può essere espanso per includere più valori nella per il futuro.

Una richiesta con fields avrebbe il seguente aspetto:

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',
});

La richiesta HTTP all'asserzione ID endpoint include il parametro fields specificato nella parte soggetta a limitazioni, con disclosure_text_shown impostato su true se non si tratta di un utente di ritorno e i campi che browser divulgato all'utente in un parametro 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

Se la parte soggetta a limitazioni ha bisogno di accedere a dati aggiuntivi dall'IdP, ad esempio l'accesso a una calendario, questo deve essere gestito con un parametro personalizzato come indicato sopra. La L'IdP restituisce un URL continue_on per richiedere l'autorizzazione.

Se fields è un array vuoto, la richiesta sarà simile a questa:

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',
});

Se fields è un array vuoto, lo user agent ignorerà l'UI per l'informativa.

Il messaggio di divulgazione non viene visualizzato in modalità widget. Nel flusso dei pulsanti, l'UI per l'informativa viene saltata completamente.

Ciò vale anche se la risposta dagli account endpoint non contiene un ID client corrispondente alla parte soggetta a limitazioni in approved_clients.

In questo caso, il valore disclosure_text_shown inviato all'asserzione ID endpoint è false nel corpo HTTP:

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

Più configURL

Più configURL consente gli IdP per ospitare più file di configurazione per un IdP, specificando accounts_endpoint e login_url nel noto lo stesso come file di configurazione.

Se accounts_endpoint e login_url vengono aggiunti al file noto, i valori provider_urls vengono ignorati per consentire all'IdP di supportare più file di configurazione. In caso contrario, provider_urls continuerà a essere applicato in modo che sia indietro compatibili.

Il noto file che supporta più configURL ha il seguente aspetto:

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

Questo ci consente di:

Mantieni la compatibilità con i file noti esistenti e la versione precedente dei browser già distribuiti.
Avere un numero arbitrario di file di configurazione, purché puntino tutti gli stessi accounts_endpoint e login_url.
Non hanno la possibilità di aggiungere entropia alla richiesta di recupero delle credenziali inviato a accounts_endpoint, poiché deve essere specificato ".well-known" livello.

Il supporto di più configURL è facoltativo e il file FedCM esistente le implementazioni possono rimanere invariate.

Etichette account personalizzate

Le etichette dell'account personalizzate consentono FedCM agli IdP di annotare gli account in modo che le parti soggette a limitazioni possano filtrarli specificando l'etichetta di configurazione in un file di configurazione. È stato possibile applicare filtri simili con il Domain Hints API e la finestra di dialogo Login l'API Hint specificando nella chiamata navigator.credentials.get(), ma le etichette personalizzate dell'account puoi filtrare gli utenti specificando il file di configurazione, che è particolarmente utile quando più configURL. Le etichette dell'account personalizzate sono sono diversi in quanto vengono forniti dal server IdP, anziché la parte soggetta a limitazioni, come l'accesso o i suggerimenti del dominio.

Esempio

Un IdP supporta due configURL rispettivamente per consumer e enterprise. La il file di configurazione consumer ha un'etichetta 'consumer' e il file di configurazione aziendale ha un'etichetta 'enterprise'.

Con questa configurazione, il file noto include accounts_endpoint e login_url per consentire più configURL.

{
  "provider_urls": [ "https://idp.example/fedcm.json" ],
  "accounts_endpoint": "https://idp.example/accounts",
  "login_url": "https://idp.example/login"
}

Quando accounts_endpoint viene fornito nel file noto, il valore provider_urls vengono ignorati. La parte soggetta a limitazioni può puntare direttamente alla rispettiva configurazione file nella chiamata navigator.credentials.get().

Il file di configurazione consumer si trova all'indirizzo https://idp.example/fedcm.json, che include Proprietà accounts che specifica 'consumer' che utilizza include.

{
  "accounts_endpoint": "https://idp.example/accounts",
  "client_metadata_endpoint": "/client_metadata",
  "login_url": "https://idp.example/login",
  "id_assertion_endpoint": "/assertion",
  "accounts": {
    "include": "consumer"
  }
}

Il file di configurazione aziendale si trova all'indirizzo https://idp.example/enterprise/fedcm.json, che include la proprietà accounts che specifica 'enterprise' utilizzando 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"
  }
}

Gli account IdP comuni endpoint (in questo esempio https://idp.example/accounts) restituisce un elenco di account che include una proprietà etichette con labels assegnato in un array per ogni account. Di seguito è riportato un esempio di risposta per un utente che dispone di due account. Uno è per consumer, l'altra è per le aziende:

{
 "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"]
  }]
}

Quando una parte soggetta a limitazioni vuole consentire l'accesso a 'enterprise' utenti, può specificare 'enterprise' configURL 'https://idp.example/enterprise/fedcm.json' nel Chiamata navigator.credentials.get():

let { token } = await navigator.credentials.get({
  identity: {
    providers: [{
      clientId: '1234',
      nonce: '234234',
      configURL: 'https://idp.example/enterprise/fedcm.json',
    },
  }
});

Di conseguenza, l'utente può firmare solo l'ID account '4567' in. L'ID account di '123' viene nascosto automaticamente dal browser in modo che l'utente non verrà fornito un account non supportato dall'IdP su questo sito.

Prova dell'origine: FedCM come indicatore di attendibilità per l'API Storage Access

Chrome 126 sta avviando una prova dell'origine di FedCM come indicatore di attendibilità per il Accesso allo spazio di archiviazione tramite Google Cloud. Con questa modifica, una precedente concessione di autorizzazioni tramite FedCM diventa un valido motivo per approva automaticamente una richiesta di accesso allo spazio di archiviazione da parte del Accesso allo spazio di archiviazione per le API.

Ciò è utile quando un iframe incorporato desidera accedere a risorse personalizzate: ad esempio, se idp.example è incorporato in rp.example e deve mostrare un una risorsa personalizzata. Se il browser limita l'accesso ai cookie di terze parti, Anche se l'utente ha eseguito l'accesso a rp.example utilizzando idp.example con FedCM, il parametro l'iframe idp.example incorporato non potrà richiedere risorse personalizzate perché le richieste non includono cookie di terze parti.

A questo scopo, idp.example deve ottenere un'autorizzazione di accesso allo spazio di archiviazione tramite il suo un iframe incorporato nel sito web e può essere ottenuto solo tramite un richiesta di autorizzazione.

Con FedCM come indicatore di attendibilità per Storage Access dell'API, I controlli delle autorizzazioni dell'API Storage Access non solo accettano la concessione che è fornita da una richiesta di accesso allo spazio di archiviazione, ma anche l'autorizzazione concessa Prompt 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();

Dopo che l'utente ha eseguito l'accesso con FedCM, l'autorizzazione viene concessa automaticamente purché l'autenticazione FedCM sia attiva. Ciò significa che, quando l'utente viene disconnesso, che richiede l'autorizzazione verrà visualizzato un prompt.

Partecipare alla prova dell'origine

Puoi provare a livello locale il bundle dell'API FedCM Continuation attivando un ambiente Chrome segnala chrome://flags#fedcm-authz su Chrome 126 o versioni successive. Puoi anche provare FedCM come indicatore di attendibilità per l'API Storage Access in locale, attivando #fedcm-with-storage-access-api su Chrome 126 o versioni successive.

Queste funzionalità sono disponibili anche come prove dell'origine. Le prove dell'origine consentono di provare nuove funzionalità e fornire feedback sulla loro usabilità, pratica ed efficacia. Per ulteriori informazioni, consulta la guida introduttiva alle prove dell'origine.

Per provare l'origine del bundle dell'API FedCM Continuation di prova, crea due token di prova dell'origine:

Registrati per la prova. Incorpora il token nell'IdP origine.
Registrati alla prova dell'origine con una casella di controllo corrispondente di terze parti selezionata. Segui le istruzioni riportate in Registrare una prova dell'origine di terze parti per il RP per incorporare il token per la parte soggetta a limitazioni.

Se vuoi abilitare l'API Continuation insieme al pulsante flusso, attiva la modalità Pulsante Origine API di prova anche:

Registrati alla prova dell'origine come terza parte. Segui le istruzioni in Registra una prova dell'origine di terze parti per la parte soggetta a limitazioni da incorporare il token per la parte soggetta a limitazioni.

Per provare FedCM come indicatore di attendibilità per l'origine dell'API Storage Access prova:

Registrati per la prova dell'origine. Incorpora il token nell'IdP origine.

La prova dell'origine del bundle dell'API Continuation e FedCM come indicatore di attendibilità per Le prove dell'origine dell'API Storage Access sono disponibili da Chrome 126.

Registrare una prova dell'origine di terze parti per la parte soggetta a limitazioni

Vai alla pagina di registrazione della prova dell'origine.
Fai clic sul pulsante Registrati e compila il modulo per richiedere un token.
Inserisci l'origine dell'IdP come Origine web.
Controlla la corrispondenza di terze parti per inserire il token con JavaScript su altre origini.
Fai clic su Invia.
Incorpora il token emesso in un sito web di terze parti.

Per incorporare il token su un sito web di terze parti, aggiungi il codice seguente all'IdP una libreria JavaScript o un SDK gestito dall'origine dell'IdP.

const tokenElement = document.createElement('meta');
tokenElement.httpEquiv = 'origin-trial';
tokenElement.content = 'TOKEN_GOES_HERE';
document.head.appendChild(tokenElement);

Sostituisci TOKEN_GOES_HERE con il tuo token.