Aktualizacje FedCM: wersje próbne źródła dla pakietu Continuation API i automatyczne przyznawanie interfejsu Storage Access API

Eiji Kitamura

Od wersji Chrome 126 deweloperzy mogą rozpocząć testowanie origin pakietu na komputery z funkcjami Federated Credential Management API (FedCM), które umożliwiają Przypadki użycia autoryzacji. Pakiet składa się z interfejsu Continuation API oraz interfejs Parameters API, który włącza obsługę podobną do procesu autoryzacji OAuth; z użyciem okna uprawnień udostępnionego przez dostawcę tożsamości. Pakiet zawiera również zawiera inne zmiany, takie jak interfejs Fields API, Wiele adresów configURLs Etykiety konta. W Chrome w wersji 126 wprowadzamy też wersję próbną origin dla Storage Access API (SAA), który automatycznie przyznaje żądania SAA, jeśli użytkownik: Użytkownik zalogował się w FedCM w przeszłości.

Wersja próbna origin: pakiet FedCM Continuation API

Pakiet FedCM Continuation API składa się z wielu rozszerzeń FedCM:

• Interfejs Continuation API
• Interfejs Parameters API
• Fields API
• Wiele adresów URL konfiguracji
• Niestandardowe etykiety konta

Interfejs API Continuation

Użytkownik loguje się w grupie objętej ograniczeniami i autoryzuje je za pomocą trybu przycisku.

Możesz zobaczyć wersję demonstracyjną interfejsu API w Glitch.

Interfejs Continuation API umożliwia Potwierdzenie identyfikatora dostawcy tożsamości opcjonalnie zwraca URL wyrenderowany przez FedCM, by umożliwić użytkownikowi kontynuowanie wieloetapowego procesu logowania się. Dzięki temu dostawca tożsamości może poprosić użytkownika o przyznanie uprawnień podmiotu zależnego (RP) wykraczających poza możliwości dostępne w obecnym interfejsie FedCM, np. z dostępem do zasobów po stronie serwera użytkownika.

Zwykle punkt końcowy potwierdzenia identyfikatora zwraca token wymagany dla uwierzytelnianie.

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

Jednak w przypadku interfejsu Continuation API potwierdzenie identyfikatora punktu końcowego zwraca właściwość continue_on, która zawiera ścieżkę bezwzględną lub względną ścieżkę do punktu końcowego potwierdzenia identyfikatora.

{
  // 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=..."
}

Gdy tylko przeglądarka otrzyma odpowiedź continue_on, nowe wyskakujące okienko wyświetli się jest otwarty i przenosi użytkownika do określonej ścieżki.

Po interakcji użytkownika ze stroną, np. przyznaniu dodatkowych uprawnień aby udostępnić dodatkowe informacje RP, strona dostawcy tożsamości może wywołać metodę IdentityProvider.resolve(), aby rozwiązać pierwotny problem navigator.credentials.get() wywołuje i zwraca token jako argument.

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

Przeglądarka samoczynnie zamknie wyskakujące okienko i zwróci token do interfejsu API. .

Jeśli użytkownik odrzuci prośbę, możesz zamknąć okno, dzwoniąc pod IdentityProvider.close()

IdentityProvider.close();

Uwaga: wyskakujące okienko zachowuje się tak, jakby noopener, noreferrer została określona (zatem window.opener to wartość null) i nie ma sposobu dla obu typów okno nadrzędne (RP) i wyskakujące okienko (IdP) do interakcji ze sobą. jedynym sposobem komunikacji powinien być jednorazowy IdentityProvider.resolve() które zamyka też wyskakujące okienko.

Uwaga: interfejs Continuation API jest dozwolony tylko w przypadku interakcji użytkownika (kliknięcia bezpośrednie). Dlatego użytkownik musi wybrać konto w tryb widżetu (z mediation: 'required') lub w przycisku tryb (co zawsze wymaga aktywacji użytkownika). Wyskakujące okienko jest jednak niedozwolone w przypadku mediation: silent W trybie widżetu mediation: optional interfejs API sprawdza, przejściowa aktywacja użytkownika po uruchomieniu automatycznego ponownego uwierzytelniania. W przeciwnym razie nie otworzy się wyskakujące okienko, a obietnica zostanie odrzucona.

Jeśli z jakiegoś powodu użytkownik zmienił konto w wyskakującym okienku (np. dostawca tożsamości oferuje opcję „przełącz użytkownika” lub w przypadku delegacji) może przyjmować opcjonalny drugi argument, który pozwala na przykład:

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

Interfejs Parameters API

Interfejs Parameters API zezwala na grupy objęte ograniczeniami. aby dostarczyć dodatkowe parametry do potwierdzenia identyfikatora . Dzięki interfejsowi Parameters API usługi RP mogą przekazywać dodatkowe parametry do dostawcy tożsamości, może prosić o uprawnienia do zasobów innych niż podstawowe logowanie. Użytkownik autoryzuje możesz je uzyskać, korzystając z kontrolowanego przez dostawcę tożsamości przepływu UX, który jest uruchamiany przez Interfejs API Continuation.

Aby korzystać z tego interfejsu API, dodaj parametry do właściwości params jako obiekt w polu navigator.credentials.get() połączenie.

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

Nazwy właściwości w obiekcie params mają przedrostek param_. W powyższego przykładu właściwość params zawiera IDP_SPECIFIC_PARAM jako '1', foo jako 'BAR', ETC jako 'MOAR' i scope jako 'calendar.readonly photos.write'. Przetłumaczone jako param_IDP_SPECIFIC_PARAM=1&param_foo=BAR&param_ETC=MOAR&param_scope=calendar.readonly%20photos.write w treści HTTP żądania:

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

Dynamiczne uzyskiwanie uprawnień

Ogólnie rzecz biorąc, użytkownikom najlepiej jest prosić o uprawnienia, gdy są a nie wtedy, gdy według dewelopera są one najłatwiejsze do wdrożenia. Dla: na przykład prosić o dostęp do aparatu, gdy użytkownik chce zrobić zdjęcie gdy tylko użytkownik znajdzie się na witryny. To samo dotyczy zasobów serwera. Tylko poproś o uprawnienia gdy są potrzebne użytkownikowi. Jest to tzw. „dynamiczna autoryzacja”.

Aby dynamicznie żądać autoryzacji za pomocą FedCM, dostawca tożsamości może:

1. Wywołaj funkcję navigator.credentials.get() z wymaganymi parametrami, które dostawca tożsamości może uzyskać. rozumienia, na przykład scope.
2. Potwierdzenie identyfikatora punkt końcowy potwierdza, że użytkownik jest już zalogowany i w odpowiedzi przesyła adres URL continue_on.
3. Przeglądarka otworzy wyskakujące okienko ze stroną uprawnień dostawcy tożsamości z prośbą o podanie dodatkowe uprawnienia pasujące do żądanych zakresów.
4. Po autoryzacji przez IdentityProvider.resolve() przez dostawcę tożsamości okno zostanie zamknięte i oryginalne wywołanie (navigator.credentials.get()) w grupie RP odpowiedni token lub kod autoryzacji, tak aby platforma RP mogła wymienić go z odpowiedni token dostępu.

Interfejs Fields API

Interfejs Fields API umożliwia grupie objętej ograniczeniami zadeklarować atrybuty konta, o które prosi dostawca tożsamości, aby przeglądarka mogła wyświetlić prawidłowy interfejs informowania w oknie FedCM; to obowiązkiem dostawcy tożsamości , aby uwzględnić żądane pola w zwróconym tokenie. Rozważ tę prośbę „profil podstawowy” w OpenID Connect a „zakresy” w OAuth.

Komunikat o ujawnianiu informacji w trybie widżetu.

.

Komunikat o ujawnianiu informacji w trybie przycisku.

Aby korzystać z interfejsu Fields API, dodaj parametry do właściwości fields jako tablicę w polu navigator.credentials.get() połączenie. Te pola mogą zawierać 'name', 'email' i 'picture', ale można je rozszerzyć, aby uwzględnić więcej wartości w w przyszłości.

Żądanie z polem fields wygląda tak:

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

Żądanie HTTP wysyłane do potwierdzenia identyfikatora punkt końcowy zawiera określony przez RP parametr fields z parametrem disclosure_text_shown ustaw jako true, jeśli to nie jest powracający użytkownik, oraz pola, w których przeglądarka została ujawniona użytkownikowi w parametrze 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

Uwaga: obecnie Chrome zgłasza wyjątek, chyba że w RPA prosi o coś fields: ['name', 'email', 'picture'] lub wcale nie korzysta z konta fields: []. W przyszłości Chrome będzie zwiększać możliwość wysyłania próśb o różne oraz zaczną akceptować podzbiory tych wartości.

Jeśli dostawca tożsamości wymaga dostępu do dodatkowych danych, takich jak kalendarz, należy to zrobić za pomocą parametru niestandardowego, jak wspomniano powyżej. Dostawca tożsamości zwraca adres URL continue_on, aby poprosić o uprawnienia.

Jeśli fields jest pustą tablicą, żądanie wygląda tak:

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

Jeśli fields jest pustą tablicą, klient użytkownika pominie interfejs komunikatu.

Komunikat o zgłoszeniu nie jest wyświetlany w trybie widżetu. Podczas tworzenia przycisku interfejs komunikatu jest całkowicie pomijany.

Dotyczy to również sytuacji, w której odpowiedź z kont punkt końcowy nie zawiera identyfikatora klienta pasującego do RP w approved_clients.

W tym przypadku żądanie disclosure_text_shown wysłane do potwierdzenia identyfikatora punkt końcowy to false w treści 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

Wiele adresów configURL

Wiele adresów configURL zezwala na dostawców tożsamości aby zmieścić wiele plików konfiguracyjnych dostawcy tożsamości, określając accounts_endpoint i login_url w znanej plik tego samego oraz pliki konfiguracyjne.

Jeśli do znanego pliku zostaną dodane accounts_endpoint i login_url, Identyfikatory provider_urls są ignorowane, aby dostawca tożsamości mógł obsługiwać wiele plików konfiguracyjnych. Jeśli tego nie zrobią, interfejs provider_urls będzie nadal działać, aż będzie działać wstecz są zgodne.

Dobrze znany plik, który obsługuje wiele adresów configURL, może wyglądać tak:

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

Dzięki temu możemy:

1. zachować zgodność wstecz i do przodu z istniejącymi dobrze znanymi plikami. oraz wcześniejszych wersji przeglądarek, które są już wdrożone na wolności.
2. mieć dowolną liczbę plików konfiguracji – o ile wszystkie wskazują je tych samych funkcji accounts_endpoint i login_url.
3. Nie mają możliwości dodania entropii do żądania pobierania z danymi uwierzytelniającymi w accounts_endpoint, bo musi być ona określona w tagu „.well-known” na poziomie 300%.

Obsługa wielu adresów configURL jest opcjonalna, a istniejący FedCM a wdrożenia mogą pozostać bez zmian.

Etykiety niestandardowe na koncie

Niestandardowe etykiety kont umożliwiają korzystanie z FedCM dostawców tożsamości do dodawania adnotacji do kont, tak aby dostawcy RP mogli je filtrować, określając etykietę w lub plik konfiguracyjny. Podobne filtrowanie było możliwe dzięki wskazówce dotyczącej domeny API i Login interfejsu Hint API, określając je w wywołaniu navigator.credentials.get(), ale etykiety konta niestandardowego może filtrować użytkowników, określając plik konfiguracyjny, co jest szczególnie przydatne, wiele adresów configURL. Etykiety konta niestandardowego są różnią się także tym, że są dostarczane przez serwer dostawcy tożsamości, a nie RP, np. logowanie lub wskazówki dotyczące domeny.

Przykład

Dostawca tożsamości obsługuje 2 adresy URL konfiguracji odpowiednio dla klientów indywidualnych i firm. plik konfiguracji klienta ma etykietę 'consumer', a plik konfiguracji przedsiębiorstwa ma etykietę 'enterprise'.

Przy takiej konfiguracji znany plik zawiera pliki accounts_endpoint oraz login_url, aby zezwolić na wiele adresów configURL.

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

Jeśli w dobrze znanym pliku podano accounts_endpoint, makro provider_urls są ignorowane. RP może wskazywać bezpośrednio odpowiednią konfigurację plików w wywołaniu navigator.credentials.get().

Plik konfiguracyjny konsumenta znajduje się pod adresem https://idp.example/fedcm.json, który zawiera Właściwość accounts, która określa 'consumer' za pomocą 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"
  }
}

Plik konfiguracyjny firmy znajduje się pod adresem https://idp.example/enterprise/fedcm.json. który zawiera właściwość accounts, która określa 'enterprise' za pomocą funkcji 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"
  }
}

Konta wspólnego dostawcy tożsamości punkt końcowy (w tym przykładzie https://idp.example/accounts) zwraca listę kont, które zawiera właściwość etykiet z przypisaną wartością labels w tablicy dla każdego konta. Poniżej znajdziesz przykładową odpowiedź dla użytkownika, który ma 2 konta. Jeden dotyczy dla użytkowników indywidualnych, a drugi jest przeznaczony dla firm:

{
 "accounts": [{
   "id": "123",
   "given_name": "John",
   "name": "John Doe",
   "email": "[e-mail]",
   "picture": "https://idp.example/profile/123",
   "labels": ["consumer"]
  }], [{
   "id": "4567",
   "given_name": "Jane",
   "name": "Jane Doe",
   "email": "[e-mail]",
   "picture": "https://idp.example/profile/4567",
   "labels": ["enterprise"]
  }]
}

Gdy grupa z ograniczonym dostępem chce umożliwić logowanie się użytkownikom 'enterprise', może określić 'enterprise' configURL 'https://idp.example/enterprise/fedcm.json' w navigator.credentials.get() – połączenie:

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

W związku z tym użytkownik może podpisać tylko identyfikator konta '4567' cal Identyfikator konta '123' jest dyskretnie ukrywany przez przeglądarkę, aby użytkownik nie zostanie udostępniony w przypadku konta, które nie jest obsługiwane przez dostawcę tożsamości w tej witrynie.

Uwaga:

.
• Etykiety to ciągi tekstowe. Jeśli tablica labels lub Pole include zawiera wartość, która nie jest ciągiem znaków, zignorowano.
• Jeśli nie określisz etykiet w adresie configURL, wszystkie konta zostaną w sekcji wyboru konta FedCM.
• Jeśli dla konta nie określono żadnych etykiet, będą one wyświetlane tylko w wybór konta, jeśli adres configURL nie określa też etykiety.
• Jeśli żadne konto nie pasuje do żądanej etykiety w przepływie widżetu (podobnie do Domains Hint API), okno FedCM wyświetla prośbę o zalogowanie się aby zalogować się na konto dostawcy tożsamości. Wyskakujące okienko logowania to bezpośrednio otwarte.

Wersja próbna origin: FedCM jako sygnał zaufania dla interfejsu Storage Access API

Chrome 126 rozpoczyna testowanie origin FedCM jako sygnału zaufania dla Dostęp do pamięci masowej API. Na tę zmianę, wcześniejsze przyznanie uprawnień przez FedCM stanie się ważnym powodem, automatycznie zatwierdzać prośbę o dostęp do pamięci masowej przez dostęp do pamięci masowej interfejsów API.

Jest to przydatne, gdy umieszczony element iframe chce uzyskać dostęp do spersonalizowanych zasobów: na przykład jeśli plik idp.example jest umieszczony w pliku rp.example i musi pokazywać tag spersonalizowany zasób. Jeśli przeglądarka ogranicza dostęp do plików cookie innych firm, nawet jeśli użytkownik jest zalogowany w rp.example przy użyciu idp.example i FedCM, parametr umieszczony element iframe IDp.example nie będzie mógł żądać spersonalizowanych zasobów bo żądania nie zawierają plików cookie innych firm.

Aby to osiągnąć, idp.example musi uzyskać dostęp do pamięci masowej za pośrednictwem elementu iframe umieszczonego na stronie. Można go uzyskać tylko za pomocą tagu o uprawnieniach.

Stosowanie FedCM jako sygnału zaufania dla dostępu do pamięci masowej API Sprawdzanie uprawnień interfejsu Storage Access API nie tylko akceptuje przyznane uprawnienia, jest przyznawana przez prośbę o dostęp do pamięci masowej, ale też zgodę przyznaną przez 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();

Gdy użytkownik zaloguje się w FedCM, uprawnienie będzie przyznawane automatycznie, o ile tylko użytkownik uwierzytelnianie FedCM jest aktywne. Oznacza to, że po rozłączeniu z użytkownikiem i poprosi o uprawnienia, wyświetli się pytanie.

Uwaga: aby zezwolić umieszczonemu elementowi iframe dostawcy tożsamości na otrzymywanie automatycznego przyznania dostępu do miejsca na dane pomimo Sama usługa FedCM nie jest wywoływana w elemencie iframe. RP musi wyraźnie dodać parametr Uprawnienia identity-credentials-get w FedCM .

Weź udział w testowaniu origin

Możesz wypróbować pakiet FedCM Continuation API lokalnie, włączając Chrome flaga chrome://flags#fedcm-authz w Chrome w wersji 126 lub nowszej. Możesz też wypróbować usługę FedCM jako sygnał zaufania dla interfejsu Storage Access API lokalnie, włączając #fedcm-with-storage-access-api w Chrome w wersji 126 lub nowszej.

Te funkcje są również dostępne jako wersje testowe origin. Wersje próbne origin pozwalają testować nowe funkcje i przesyłać opinie na temat ich użyteczności, praktyczności i skuteczności. Więcej informacji znajdziesz w artykule o pierwszych krokach z testowaniem origin.

Aby wypróbować pochodzenie pakietu interfejsu FedCM Continuation API wersji próbnej, utwórz 2 tokeny próbne origin:

• Zarejestruj się, aby skorzystać z okresu próbnego. Umieszczanie tokena u dostawcy tożsamości origin.
• Zarejestruj się w celu testowania origin, zaznaczając pole wyboru firmy zewnętrznej. Postępuj zgodnie z instrukcjami podanymi w artykule Rejestrowanie wersji próbnej origin innych firm na potrzeby RP, aby umieścić token dla grupy objętej ograniczeniami.

Jeśli chcesz włączyć interfejs Continuation API wraz z przyciskiem przepływ, włącz tryb przycisku Pochodzenie interfejsu API okres próbny oraz:

• Zarejestruj się w programie testowania origin jako osoba trzecia. Postępuj zgodnie z instrukcjami podanymi w artykule Zarejestruj zewnętrzną wersję testowania origin dla stron objętych ograniczeniami, którą będzie można umieścić czyli token RP.

Aby wypróbować FedCM jako sygnał zaufania dla źródła interfejsu Storage Access API wersja próbna:

• Zarejestruj się, aby wziąć udział w programie testowania origin. Umieszczanie tokena u dostawcy tożsamości origin.

Test origin pakietu interfejsu Continuation API i FedCM jako sygnał zaufania dla Testowanie origin interfejsu Storage Access API jest dostępne w Chrome 126.

Rejestrowanie wersji próbnej origin innych firm na potrzeby RP

1. Otwórz stronę rejestracji wersji próbnej origin.
2. Kliknij przycisk Zarejestruj i wypełnij formularz, aby poprosić o token.
3. Wpisz źródło dostawcy tożsamości jako Web Origin.
4. Zaznacz Dopasowanie zewnętrzne, aby wstawić token za pomocą JavaScriptu w innych źródłach.
5. Kliknij Prześlij.
6. Umieść wydany token na stronie internetowej innej firmy.

Aby umieścić token w witrynie innej firmy, dodaj ten kod do dostawcy tożsamości Biblioteka JavaScript lub pakiet SDK udostępniany ze źródła dostawcy tożsamości.

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

Zastąp TOKEN_GOES_HERE własnym tokenem.

Uwaga: jeśli interfejs API FedCM jest wywoływany przez grupę objętej ograniczeniami, a nie przez skrypt wczytywany przez dostawcę tożsamości, to RP muszą samodzielnie zarejestrować swoje źródło i przeprowadzić testy własnych origin.