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
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();
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¶m_foo=BAR¶m_ETC=MOAR¶m_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¶m_IDP_SPECIFIC_PARAM=1¶m_foo=BAR¶m_ETC=MOAR¶m_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:
- Wywołaj funkcję
navigator.credentials.get()
z wymaganymi parametrami, które dostawca tożsamości może uzyskać. rozumienia, na przykładscope
. - Potwierdzenie identyfikatora
punkt końcowy
potwierdza, że użytkownik jest już zalogowany i w odpowiedzi przesyła adres URL
continue_on
. - 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.
- 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.
![Wiadomość o ujawnieniu w trybie widżetu.](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-widget.jpg?authuser=8&hl=pl)
![Komunikat wyświetlany w trybie przycisku.](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/fedcm-126-with-disclosure-button.jpg?authuser=8&hl=pl)
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
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.](https://developers.google.cn/static/privacy-sandbox/assets/images/blog/fedcm-126-without-disclosure-widget.jpg?authuser=8&hl=pl)
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:
- 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.
- mieć dowolną liczbę plików konfiguracji – o ile wszystkie wskazują je
tych samych funkcji
accounts_endpoint
ilogin_url
. - 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": "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"]
}]
}
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.
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.
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
- Otwórz stronę rejestracji wersji próbnej origin.
- Kliknij przycisk Zarejestruj i wypełnij formularz, aby poprosić o token.
- Wpisz źródło dostawcy tożsamości jako Web Origin.
- Zaznacz Dopasowanie zewnętrzne, aby wstawić token za pomocą JavaScriptu w innych źródłach.
- Kliknij Prześlij.
- 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.