Implementeer een identiteitsoplossing met FedCM aan de kant van de identiteitsprovider

De implementatie van FedCM omvat verschillende kernstappen voor zowel de identiteitsaanbieder (IdP) als de vertrouwende partij (RP) . Raadpleeg de documentatie voor meer informatie over de implementatie van FedCM aan de kant van de RP .

IdP's moeten de volgende stappen doorlopen om FedCM te implementeren:

1. Maak een bekend bestand aan.
2. Maak een configuratiebestand aan.
3. Maak de volgende eindpunten aan:
   • Account-eindpunt
   • ID-assertie-eindpunt
   • [optioneel] Eindpunt loskoppelen
   • [optioneel] Eindpunt voor clientmetadata
   • Aanmeldingspunt
4. Informeer de browser over de inlogstatus van de gebruiker .

Maak een bekend bestand aan.

Om te voorkomen dat trackers misbruik maken van de API , moet een bekend bestand worden aangeboden vanuit /.well-known/web-identity van de eTLD+1 van de IdP.

Het bekende bestand kan de volgende eigenschappen bevatten:

Als de IdP-eindpunten bijvoorbeeld worden aangeboden via https://accounts.idp.example/ , moeten ze een bekend bestand aanbieden op https://idp.example/.well-known/web-identity , evenals een IdP-configuratiebestand . Hier volgt een voorbeeld van de inhoud van een bekend bestand:

  {
     // You must include accounts_endpoint and login_url if your
     // config file specifies a client_metadata_endpoint
    "accounts_endpoint": "https://accounts.idp.example/accounts",
    "login_url": "https://accounts.idp.example/login"
  }

IdP's kunnen meerdere configuratiebestanden voor een IdP gebruiken door accounts_endpoint en login_url in het bekende bestand te specificeren. Deze functie kan in de volgende gevallen nuttig zijn:

• Een identiteitsprovider (IdP) moet meerdere verschillende test- en productieconfiguraties ondersteunen.
• Een identiteitsprovider (IdP) moet per regio verschillende configuraties ondersteunen (bijvoorbeeld eu-idp.example en us-idp.example ).

Om meerdere configuraties te ondersteunen (bijvoorbeeld om onderscheid te maken tussen test- en productieomgeving), moet de IdP accounts_endpoint en login_url specificeren:

  {
    // This property is required, but will be ignored when IdP supports
    // multiple configs (when `accounts_endpoint` and `login_url` are
    // specified), as long as `accounts_endpoint` and `login_url` in
    // that config file match those in the well-known file.
    "provider_urls": [ "https://idp.example/fedcm.json" ],

    // Specify accounts_endpoint and login_url properties to support
    // multiple config files.
    // Note: The accounts_endpoint and login_url must be identical
    // across all config files. Otherwise,
    // the configurations won't be supported.
    "accounts_endpoint": "https://idp.example/accounts",
    "login_url": "https://idp.example/login"
  }

Maak een IdP-configuratiebestand en eindpunten aan.

Het configuratiebestand van de identiteitsprovider (IdP) bevat een lijst met vereiste eindpunten voor de browser. IdP's moeten een of meerdere configuratiebestanden hosten, inclusief de vereiste eindpunten en URL's. Alle JSON-reacties moeten worden aangeboden met het contenttype application/json .

De URL van het configuratiebestand wordt bepaald door de waarden die worden doorgegeven aan de aanroep navigator.credentials.get() die wordt uitgevoerd op een RP . De RP zal de URL van het configuratiebestand doorgeven voor elke identiteitsprovider:

  // Executed on RP's side:
  try {
    const credential = await navigator.credentials.get({
      identity: {
        providers: [
          {
            // To allow users to sign in with the IdP1 using FedCM, RP specifies the IdP's config file URL:
            configUrl: 'https://idp1.example/foo.json', // first IdP
            clientId: '123',
          },
          // To allow users to sign in with the IdP2 using FedCM, RP specifies the IdP's config file URL.
          // Note that multiple IdPs in a single get() are supported from Chrome 136.
          {
            configUrl: 'https://idp2.example/bar.json', // second IdP
            clientId: '456',
          },
        ],
      },
    });

    const token = credential.token;
    // Get the current IdP's configURL to identify which provider the user is signed in with
    const currentIdpConfigUrl = credential.configURL;
    if (currentIdpConfigUrl === 'https://idp1.example/foo.json') {
      // handle the case where the user signed in with idp1
    } else if (currentIdpConfigUrl === 'https://idp2.example/bar.json') {
      // handle the case where the user signed in with idp2
    }
  } catch (error) {
    // handle error
  }

De browser haalt het configuratiebestand op met een GET verzoek zonder de Origin header of de Referer header. Het verzoek bevat geen cookies en volgt geen redirects. Dit voorkomt effectief dat de IdP te weten komt wie het verzoek heeft gedaan en welke RP probeert verbinding te maken. Bijvoorbeeld:

  GET /config.json HTTP/1.1
  Host: accounts.idp.example
  Accept: application/json
  Sec-Fetch-Dest: webidentity

De IdP moet een configuratie-eindpunt implementeren dat reageert met een JSON-object. De JSON bevat de volgende eigenschappen:

Hier is een voorbeeld van een reactie van de IdP:

  {
    "accounts_endpoint": "/accounts.example",
    "client_metadata_endpoint": "/client_metadata.example",
    "id_assertion_endpoint": "/assertion.example",
    "disconnect_endpoint": "/disconnect.example",
    "login_url": "/login",
    // When RPs use this config file, only those accounts will be
    //returned that include `developer` label in the accounts endpoint.
    "account_label": "developer",
    "supports_use_other_account": true,
    "branding": {
      "background_color": "green",
      "color": "#FFEEAA",
      "icons": [{
        "url": "https://idp.example/icon.ico",
        "size": 25
      }]
    }
  }

Zodra de browser het configuratiebestand heeft opgehaald, stuurt hij vervolgverzoeken naar de IdP-eindpunten:

Gebruik een ander account

Gebruikers kunnen overschakelen naar een ander account dan het account waarmee ze zijn ingelogd, als de identiteitsprovider meerdere accounts ondersteunt of het bestaande account kan vervangen.

Om de gebruiker de mogelijkheid te bieden andere accounts te kiezen, moet de identiteitsprovider deze functie in het configuratiebestand specificeren:

  {
    "accounts_endpoint" : "/accounts.example",
    "supports_use_other_account": true
  }

Accounts-eindpunt

Het accounts-eindpunt van de IdP retourneert een lijst met accounts waarmee de gebruiker is aangemeld bij de IdP. Als de IdP meerdere accounts ondersteunt, retourneert dit eindpunt alle aangemelde accounts.

De browser verstuurt een GET verzoek met cookies met SameSite=None , maar zonder client_id parameter, Origin header of Referer header. Dit voorkomt effectief dat de IdP te weten komt bij welke RP de gebruiker probeert in te loggen. Bijvoorbeeld:

  GET /accounts.example HTTP/1.1
  Host: accounts.idp.example
  Accept: application/json
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

Na ontvangst van het verzoek moet de server het volgende doen:

1. Controleer of het verzoek een Sec-Fetch-Dest: webidentity HTTP-header bevat.
2. Koppel de sessiecookies aan de ID's van de reeds ingelogde accounts.
3. Reageer met de lijst van accounts.

De browser verwacht een JSON-antwoord met een eigenschap accounts die een array met accountinformatie bevat, met de volgende eigenschappen:

Voorbeeld van een antwoordtekst:

  {
    "accounts": [{
      "id": "1234",
      "given_name": "John",
      "name": "John Doe",
      "email": "john_doe@idp.example",
      "picture": "https://idp.example/profile/123",
      // Ids of those RPs where this account can be used
      "approved_clients": ["123", "456", "789"],
      // This account has 'login_hints`. When an RP calls `navigator.credentials.get()`
      // with a `loginHint` value specified, for example, `exampleHint`, only those
      // accounts will be shown to the user whose 'login_hints' array contains the `exampleHint`.
      "login_hints": ["demo1", "exampleHint"],
      // This account is labelled. IdP can implement a specific config file for a
      // label, for example, `https://idp.example/developer-config.json`. Like that
      // RPs can filter out accounts by calling `navigator.credentials.get()` with
      // `https://idp.example/developer-config.json` config file.
      "label_hints": ["enterprise", "developer"]
    }, {
      "id": "5678",
      "given_name": "Johnny",
      "name": "Johnny",
      "email": "johnny@idp.example",
      "picture": "https://idp.example/profile/456",
      "approved_clients": ["abc", "def", "ghi"],
      "login_hints": ["demo2"],
      "domain_hints": ["@domain.example"]
    }]
  }

Als de gebruiker niet is ingelogd, reageer dan met HTTP 401 (Unauthorized).

De lijst met geretourneerde accounts wordt door de browser verwerkt en is niet beschikbaar voor de RP.

ID-assertie-eindpunt

Het ID-assertie-eindpunt van de IdP retourneert een bewering voor de ingelogde gebruiker. Wanneer de gebruiker inlogt op een RP-website met de aanroep navigator.credentials.get() , stuurt de browser een POST verzoek met cookies met SameSite=None en een content-type van application/x-www-form-urlencoded naar dit eindpunt met de volgende informatie:

Voorbeeld van een HTTP-header:

  POST /assertion.example HTTP/1.1
  Host: accounts.idp.example
  Origin: https://rp.example/
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x23223
  Sec-Fetch-Dest: webidentity

  // disclosure_text_shown is set to 'false', as the 'name' field value is missing in 'fields' array
  // params value is serialized to JSON and then percent-encoded.
  account_id=123&client_id=client1234&disclosure_text_shown=false&is_auto_selected=true&params=%22%7B%5C%22nonce%5C%22%3A%5C%22nonce-value%5C%22%7D%22.%0D%0A4&fields=email,picture&disclosure_shown_for=email,picture

Na ontvangst van het verzoek moet de server het volgende doen:

1. Reageer op het verzoek met CORS (Cross-Origin Resource Sharing) .
2. Controleer of het verzoek een Sec-Fetch-Dest: webidentity HTTP-header bevat.
3. Vergelijk de Origin header met de RP-origin die is bepaald door de client_id . Weiger de aanvraag als deze niet overeenkomt.
4. Vergelijk account_id met de ID van het reeds ingelogde account. Weiger de aanvraag als deze niet overeenkomt.
5. Reageer met een token. Als het verzoek wordt afgewezen, reageer dan met een foutmelding .

De IdP kan zelf bepalen hoe het token wordt uitgegeven. Over het algemeen wordt het token ondertekend met informatie zoals de account-ID, client-ID, de herkomst van de uitgever en een nonce, zodat de RP kan controleren of het token echt is.

De browser verwacht een JSON-antwoord met de volgende eigenschap:

Het teruggestuurde token wordt door de browser aan de Relying Party (RP) doorgegeven, zodat de RP de authenticatie kan valideren.

{
  // IdP can respond with a token object to authenticate the user
  "token": {
    "access_token": "a1b2c3d4e5f6...",
    "user_info": {
      "email": "jane.doe@company.example",
      "given_name": "Jane",
      "family_name": "Doe"
    }
  }
}

Ga verder met de functie

De identiteitsprovider (IdP) kan een omleidings-URL in de reactie van het ID-assertie-eindpunt opnemen om een ​​aanmeldingsproces in meerdere stappen mogelijk te maken. Dit is handig wanneer de IdP bijvoorbeeld aanvullende informatie of machtigingen moet opvragen:

• Toestemming om toegang te krijgen tot de serverbronnen van de gebruiker.
• Controle of de contactgegevens actueel zijn.
• Ouderlijk toezicht.

Het ID-assertie-eindpunt kan een continue_on eigenschap retourneren die een absoluut of relatief pad naar het ID-assertie-eindpunt bevat.

  {
    // In the id_assertion_endpoint, instead of returning a typical
    // "token" response, the IdP decides that it needs the user to
    // continue on a dialog window:
    "continue_on": "https://idp.example/continue_on_url"
  }

Als het antwoord de parameter continue_on bevat, wordt een nieuw dialoogvenster geopend dat de gebruiker naar het opgegeven pad leidt. Na de interactie van de gebruiker met de continue_on pagina moet de IdP IdentityProvider.resolve() aanroepen met het token als argument, zodat de belofte van de oorspronkelijke navigator.credentials.get() -aanroep kan worden afgehandeld.

  document.getElementById('example-button').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);
  });

De browser sluit vervolgens automatisch het dialoogvenster en stuurt het token terug naar de API-aanroeper. Een eenmalige aanroep van IdentityProvider.resolve() is de enige manier waarop het hoofdvenster (RP) en het dialoogvenster (IdP) met elkaar kunnen communiceren.
Als de gebruiker het verzoek afwijst, kan de IdP het venster sluiten door IdentityProvider.close() aan te roepen.

  IdentityProvider.close();

De Continuation API vereist expliciete gebruikersinteractie (klikken) om te functioneren. Hieronder wordt uitgelegd hoe de Continuation API werkt met verschillende bemiddelingsmodi :

• In passive modus :
  • mediation: 'optional' (standaard): de Continuation API werkt alleen met een gebruikersactie, zoals klikken op een knop op de pagina of in de FedCM-gebruikersinterface. Wanneer automatische herauthenticatie wordt geactiveerd zonder gebruikersactie, wordt er geen dialoogvenster geopend en wordt de promise afgewezen.
  • mediation: 'required' : Vraagt ​​altijd om interactie van de gebruiker, zodat de Continuation API altijd werkt.
• In actieve modus :
  • Gebruikersactivering is altijd vereist. De Continuation API is altijd compatibel.

Als de gebruiker om welke reden dan ook zijn account in het dialoogvenster heeft gewijzigd (bijvoorbeeld omdat de identiteitsprovider een functie "ander account gebruiken" aanbiedt, of in gevallen van delegatie), accepteert de resolve-aanroep een optioneel tweede argument waarmee iets als het volgende mogelijk is:

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

Geef een foutmelding terug.

Het id_assertion_endpoint kan ook een "error"-respons retourneren, die twee optionele velden bevat:

• code : De IdP kan een van de bekende fouten uit de door OAuth 2.0 gespecificeerde foutenlijst kiezen ( invalid_request , unauthorized_client , access_denied , server_error en temporarily_unavailable ) of een willekeurige tekenreeks gebruiken. In het laatste geval geeft Chrome de foutinterface weer met een algemene foutmelding en stuurt de code door naar de RP.
• url : Dit veld verwijst naar een leesbare webpagina met informatie over de fout, zodat gebruikers aanvullende informatie over de fout krijgen. Dit veld is nuttig voor gebruikers omdat browsers geen uitgebreide foutmeldingen in hun ingebouwde gebruikersinterface kunnen weergeven. Denk bijvoorbeeld aan links naar vervolgstappen of contactgegevens van de klantenservice. Als een gebruiker meer wil weten over de foutdetails en hoe deze op te lossen, kan hij of zij de opgegeven pagina in de browser bezoeken voor meer informatie. De URL moet dezelfde site zijn als de IdP configURL .

  // id_assertion_endpoint response
  {
    "error" : {
      "code": "access_denied",
      "url" : "https://idp.example/error?type=access_denied"
    }
  }

Aangepaste accountlabels

Met aangepaste accountlabels kan de IdP gebruikersaccounts van labels voorzien, en kan de RP ervoor kiezen om alleen accounts met specifieke labels op te halen door de configURL voor dat specifieke label op te geven. Dit kan handig zijn wanneer een RP accounts moet filteren op basis van specifieke criteria, bijvoorbeeld om alleen rol-specifieke accounts weer te geven, zoals "developer" of "hr" .

Vergelijkbare filtering is mogelijk met behulp van de functies Domain Hint en Login Hint , door deze te specificeren in de aanroep navigator.credentials.get() . Aangepaste accountlabels kunnen echter gebruikers filteren door het configuratiebestand te specificeren, wat vooral handig is wanneer meerdere configURL's worden gebruikt. Aangepaste accountlabels verschillen ook doordat ze door de IdP-server worden verstrekt, in tegenstelling tot de RP, zoals login- of domeinhints.

Stel je een identiteitsprovider (IdP) voor die onderscheid wil maken tussen "developer" en "hr" -accounts. Om dit te bereiken, moet de IdP twee configURL's ondersteunen, één voor "developer" en één voor "hr" :

• Het ontwikkelaarsconfiguratiebestand https://idp.example/developer/fedcm.json heeft een label "developer" , en het bedrijfsconfiguratiebestand https://idp.example/hr/fedcm.json heeft een label "hr" zoals hieronder weergegeven:

  // The developer config file at `https://idp.example/developer/fedcm.json`
  {
    "accounts_endpoint": "https://idp.example/accounts",
    "client_metadata_endpoint": "/client_metadata",
    "login_url": "https://idp.example/login",
    "id_assertion_endpoint": "/assertion",
    "account_label": "developer"
  }

  // The hr config file at `https://idp.example/hr/fedcm.json`
  {
    "accounts_endpoint": "https://idp.example/accounts",
    "client_metadata_endpoint": "/client_metadata",
    "login_url": "https://idp.example/login",
    "id_assertion_endpoint": "/assertion",
    "account_label": "hr"
  }

• Met een dergelijke configuratie moet het bekende bestand accounts_endpoint en login_url bevatten om meerdere configURLs mogelijk te maken:

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

• Het standaard IdP -accounts-eindpunt (in dit voorbeeld https://idp.example/accounts ) retourneert een lijst met accounts, inclusief een eigenschap label_hints met toegewezen labels in een array voor elk account:

  {
  "accounts": [{
    "id": "123",
    "given_name": "John",
    "name": "John Doe",
    "email": "john_doe@idp.example",
    "picture": "https://idp.example/profile/123",
    "label_hints": ["developer"]
    }], [{
    "id": "4567",
    "given_name": "Jane",
    "name": "Jane Doe",
    "email": "jane_doe@idp.example",
    "picture": "https://idp.example/profile/4567",
    "label_hints": ["hr"]
    }]
  }

Wanneer een RP gebruikers met de status "hr" wil toestaan ​​in te loggen, kan deze de configURL https://idp.example/hr/fedcm.json specificeren in de aanroep navigator.credentials.get() :

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

Hierdoor is alleen account-ID 4567 beschikbaar voor de gebruiker om in te loggen. Account-ID 123 wordt door de browser stilzwijgend verborgen, zodat de gebruiker geen account krijgt aangeboden dat niet door de identiteitsprovider op deze site wordt ondersteund.

Aanvullende aandachtspunten:

• Labels zijn tekenreeksen. Als de array label_hints of het veld account_label een waarde gebruikt die geen tekenreeks is, wordt die waarde genegeerd.
• Als er geen labels zijn opgegeven in de configURL , worden alle accounts weergegeven in de FedCM-accountkiezer.
• Als er geen labels zijn opgegeven voor een account, wordt dit account alleen in de accountkiezer weergegeven als de configURL ook geen label bevat.
• Als er in de passieve modus geen account wordt gevonden dat overeenkomt met het gevraagde label (vergelijkbaar met de Domain Hint-functie), toont het FedCM-dialoogvenster een inlogprompt waarmee de gebruiker zich kan aanmelden bij een IdP-account. In de actieve modus wordt het inlogdialoogvenster direct geopend.

Eindpunt loskoppelen

Door IdentityCredential.disconnect() aan te roepen, stuurt de browser een cross-origin POST verzoek met cookies met SameSite=None en een content-type van application/x-www-form-urlencoded naar dit disconnect-eindpunt met de volgende informatie:

  POST /disconnect.example HTTP/1.1
  Host: idp.example
  Origin: rp.example
  Content-Type: application/x-www-form-urlencoded
  Cookie: 0x123
  Sec-Fetch-Dest: webidentity

  account_hint=account456&client_id=rp123

Na ontvangst van het verzoek moet de server het volgende doen:

1. Reageer op het verzoek met CORS (Cross-Origin Resource Sharing) .
2. Controleer of het verzoek een Sec-Fetch-Dest: webidentity HTTP-header bevat.
3. Vergelijk de Origin header met de RP-origin die is bepaald door de client_id . Weiger de aanvraag als deze niet overeenkomt.
4. Vergelijk account_hint met de ID's van de reeds ingelogde accounts.
5. Ontkoppel het gebruikersaccount van de RP.
6. Stuur de browser de geïdentificeerde gebruikersaccountgegevens in JSON-formaat.

Een voorbeeld van een JSON-antwoordpayload ziet er als volgt uit:

  {
    "account_id": "account456"
  }

Als de IdP daarentegen wil dat de browser alle accounts die aan de RP zijn gekoppeld, loskoppelt, moet een tekenreeks worden doorgegeven die niet overeenkomt met een account-ID, bijvoorbeeld "*" .

Client metadata-eindpunt

Het clientmetadata-eindpunt van de IdP retourneert de metadata van de relying party, zoals het privacybeleid, de servicevoorwaarden en logo-pictogrammen van de RP. RP's dienen vooraf links naar hun privacybeleid en servicevoorwaarden aan de IdP te verstrekken. Deze links worden weergegeven in het aanmelddialoogvenster wanneer de gebruiker zich nog niet bij de RP heeft geregistreerd via de IdP.

De browser verstuurt een GET verzoek met de client_id navigator.credentials.get zonder cookies. Als de FedCM API wordt aangeroepen vanuit een andere site, wordt ook de parameter top_frame_origin meegestuurd. Bijvoorbeeld:

  GET /client_metadata.example?client_id=1234&top_frame_origin=https%3A%2F%2Ftop-frame.example HTTP/1.1
  Host: accounts.idp.example
  Origin: https://rp.example/
  Accept: application/json
  Sec-Fetch-Dest: webidentity

Na ontvangst van het verzoek moet de server het volgende doen:

1. Bepaal de RP voor de client_id .
2. [Optioneel] Als top_frame_origin in het verzoek is opgenomen, controleer dan of de RP en het topframe dezelfde partij zijn om te bepalen of het iframe-domein door de browser moet worden aangeroepen. IdP's dienen hiervoor hun eigen logica te definiëren.
3. Reageer met de klantmetadata.

De eigenschappen voor het clientmetadata-eindpunt omvatten:

De browser verwacht een JSON-antwoord van het eindpunt:

  {
    "privacy_policy_url": "https://rp.example/privacy_policy.html",
    "terms_of_service_url": "https://rp.example/terms_of_service.html",
    "icons": [{
          "url": "https://rp.example/rp-icon.ico",
          "size": 40
      }]
  }

De geretourneerde clientmetadata wordt door de browser gebruikt en is niet beschikbaar voor de RP.

Inlog-URL

Dit eindpunt wordt gebruikt om de gebruiker te laten inloggen bij de IdP.

Met de Login Status API moet de IdP de inlogstatus van de gebruiker aan de browser doorgeven. De status kan echter niet synchroon lopen, bijvoorbeeld wanneer de sessie verloopt . In zo'n geval kan de browser de gebruiker dynamisch laten inloggen bij de IdP via de URL van de inlogpagina die is opgegeven in het ` login_url veld van het IdP-configuratiebestand .

Het FedCM-dialoogvenster toont een bericht waarin wordt voorgesteld om in te loggen, zoals te zien is in de volgende afbeelding.

Wanneer de gebruiker op de knop ' Doorgaan' klikt, opent de browser een dialoogvenster voor de inlogpagina van de identiteitsprovider.

Het dialoogvenster is een gewoon browservenster met first-party cookies. Alles wat er binnen het dialoogvenster gebeurt, is de verantwoordelijkheid van de IdP, en er zijn geen vensterhandles beschikbaar om een ​​cross-origin communicatieverzoek naar de RP-pagina te sturen. Nadat de gebruiker is ingelogd, moet de IdP het volgende doen:

• Verzend de header Set-Login: logged-in of roep de API navigator.login.setStatus("logged-in") aan om de browser te laten weten dat de gebruiker is ingelogd.
• Roep IdentityProvider.close() aan om het dialoogvenster te sluiten.

Informeer de browser over de inlogstatus van de gebruiker.

De Login Status API is een mechanisme waarmee een website, met name een identiteitsprovider (IdP), de browser informeert over de inlogstatus van de gebruiker bij de IdP. Met deze API kan de browser onnodige verzoeken aan de IdP verminderen en potentiële timingaanvallen tegengaan .

IdP's kunnen de inlogstatus van de gebruiker aan de browser doorgeven door een HTTP-header te verzenden of een JavaScript API aan te roepen wanneer de gebruiker is ingelogd bij de IdP of wanneer de gebruiker is uitgelogd bij al zijn IdP-accounts. Voor elke IdP (geïdentificeerd door de configuratie-URL) houdt de browser een variabele bij die de inlogstatus weergeeft met mogelijke waarden:

• logged-in
• logged-out
• unknown (standaard)

Om aan te geven dat de gebruiker is ingelogd, stuurt u een Set-Login: logged-in HTTP-header mee in een topniveau-navigatie of een subresource-verzoek op dezelfde site bij de IdP-origin:

  Set-Login: logged-in

Als alternatief kunt u de JavaScript-methode navigator.login.setStatus('logged-in') aanroepen vanuit de IdP-origin in een navigatie op het hoogste niveau:

  navigator.login.setStatus('logged-in')

De inlogstatus van de gebruiker wordt ingesteld op logged-in .

Om aan te geven dat de gebruiker is uitgelogd van al zijn accounts, stuurt u een Set-Login: logged-out HTTP-header mee in een topniveau-navigatie of een subresource-verzoek op dezelfde site bij de IdP-origin:

  Set-Login: logged-out

Als alternatief kunt u de JavaScript API-aanroep ` navigator.login.setStatus('logged-out') vanuit de IdP-origin in een navigatie op het hoogste niveau aanroepen:

  navigator.login.setStatus('logged-out')

De inlogstatus van de gebruiker wordt ingesteld op logged-out .

De status unknown wordt ingesteld voordat de IdP een signaal verzendt via de Login Status API. De browser doet een verzoek aan het accounts-eindpunt van de IdP en werkt de status bij op basis van het antwoord van dat eindpunt.

• Als het eindpunt een lijst met actieve accounts retourneert, wijzig dan de status naar logged-in en open het FedCM-dialoogvenster om die accounts weer te geven.
• Als het eindpunt geen accounts retourneert, moet de status worden bijgewerkt naar logged-out en moet de FedCM-aanroep mislukken.

Laat de gebruiker inloggen via een dynamisch inlogproces.

Hoewel de identiteitsprovider (IdP) de browser continu op de hoogte houdt van de inlogstatus van de gebruiker, kan er een synchronisatieprobleem ontstaan, bijvoorbeeld wanneer de sessie verloopt. De browser probeert een verzoek met inloggegevens naar het accounts-eindpunt te sturen wanneer de inlogstatus ' logged-in is, maar de server retourneert geen accounts omdat de sessie niet langer beschikbaar is. In zo'n geval kan de browser de gebruiker dynamisch laten inloggen bij de IdP via een dialoogvenster .