---
title: "Konfiguracja SSO z Google Workspace"
description: "Zarejestruj połączenie SAML lub OIDC Bird w Google Workspace, wyłącz podpisywanie odpowiedzi, włącz dostęp użytkowników i uwzględnij opóźnienie konfiguracji Google."
canonical: "https://bird.com/pl-pl/dokumentacja/knowledge-base/account-security/sso-google-workspace"
---

# Konfiguracja SSO z Google Workspace

Ta strona opisuje część konfiguracji SSO po stronie Google Workspace. Część po stronie Bird (weryfikacja domeny, testowanie, aktywacja i wymuszanie SSO) jest taka sama dla każdego dostawcy i znajduje się na stronie [SSO i provisioning](/docs/knowledge-base/account-security/sso).

Google i Bird potrzebują nawzajem swoich wartości, więc punkt startowy zależy od protokołu. Miej obie strony otwarte podczas pracy.

Dwa zachowania Google powodują większość nieudanych pierwszych testów i żadne z nich nie zgłasza niczego do Bird:

- **Włącz dostęp użytkowników przed testem.** Nowa niestandardowa aplikacja SAML jest domyślnie wyłączona dla wszystkich. Dopóki nie włączysz jej dla osób, które będą się logować, Google odmawia po swojej stronie, a okno testowe nie pokazuje nic.
- **Odczekaj kilka minut po zapisaniu.** Google stosuje zmiany w aplikacji SAML (podpisywanie odpowiedzi, format Name ID, dostęp użytkowników) z opóźnieniem około dwóch do czterech minut. Test uruchomiony w tym oknie raportuje poprzednią konfigurację, co wygląda jak problem po stronie Bird, ale nim nie jest.

## SAML

Zacznij w Bird dla SAML. Entity ID i Assertion Consumer Service URL połączenia SAML wynikają z samego połączenia, więc utwórz je z opcją **I have not set up my provider yet**, zarejestruj wyświetlone wartości, a potem wróć do **Supply the details**. [Konfiguracja SAML bez wartości zastępczych](/docs/knowledge-base/account-security/sso) opisuje ten proces.

Google nie publikuje URL metadanych dla niestandardowej aplikacji SAML. Pobierz plik metadanych z konsoli Google Admin i wklej jego zawartość do **Supply the details** w połączeniu Bird, wybierając opcję dokumentu metadanych.

Nazwy pól w Google nie odpowiadają nazwom w Bird:

| W Bird, w sekcji **Register these with your identity provider** | W Google Workspace   |
| --------------------------------------------------------------- | -------------------- |
| Assertion Consumer Service URL                                  | ACS URL              |
| Entity ID                                                       | Entity ID            |
| Sign-in URL for this connection                                 | Start URL (optional) |

### Wyłącz Signed response

Pozostaw **Signed response** odznaczone. Po zaznaczeniu Google podpisuje odpowiedź, a asercję wewnątrz niej pozostawia niepodpisaną, a Bird weryfikuje podpis samej asercji, więc każde logowanie jest odrzucane z błędem podpisu, który wygląda jak problem z certyfikatem. Odznaczenie przywraca podpisaną asercję i logowanie działa poprawnie.

### Identyfikuj członków po adresie e-mail

Ustaw **Name ID format** na `EMAIL`. Pozostałe formaty Google nie działają z Bird:

- `UNSPECIFIED` jest odrzucany bezwarunkowo.
- `PERSISTENT` jest odrzucany, ponieważ format nie odpowiada temu, którego oczekuje połączenie. Google i tak wysyła adres e-mail członka jako wartość, więc nie jest to nieprzejrzysty, nigdy nieprzypisywany ponownie identyfikator, jaki powinien nieść format persistent.

Google nie oferuje nieprzejrzystego identyfikatora dla NameID, więc `EMAIL` jest jedynym użytecznym wyborem. To sprawia, że adres jest trwały dla każdego, kto loguje się przez to połączenie: jeśli Twoja organizacja kiedykolwiek go przypisze komuś innemu, nowa osoba odziedziczy konto Bird. Przeczytaj [Jak identyfikowani są członkowie](/docs/knowledge-base/account-security/sso), zanim zaczniesz na tym polegać.

### Ważność asercji i certyfikaty

Google podpisuje asercje ważne od pięciu minut przed wystawieniem do pięciu minut po, co Bird akceptuje.

Google zarządza certyfikatem podpisu i jego datą wygaśnięcia i nie daje Ci kontroli nad rotacją w niestandardowej aplikacji SAML. Zanotuj datę wygaśnięcia widoczną w połączeniu Bird i zaplanuj wymianę metadanych przed jej upływem, ponieważ w dniu wygaśnięcia każde logowanie przez to połączenie przestaje działać.

## OIDC

Zacznij w konsoli Google Cloud dla OIDC. Bird potrzebuje issuera, client ID i client secret, aby utworzyć połączenie OIDC, więc najpierw zarejestruj aplikację w Google. **Redirect URI** Bird jest taki sam dla każdego połączenia i jest widoczny w **Add connection** jeszcze przed utworzeniem czegokolwiek, więc możesz go zarejestrować od razu.

Utwórz poświadczenia klienta OAuth w konsoli Google Cloud dla projektu obsługującego użytkowników Workspace i skopiuj client ID oraz secret do Bird z `https://accounts.google.com` jako **Issuer**. Bird odczytuje stamtąd dokument discovery i uwierzytelnia się w endpoincie tokenowym za pomocą `client_secret_basic`.

Zarejestruj **Redirect URI** Bird jako autoryzowany redirect URI w kliencie.

Ścieżka OIDC Google nie ma kroku z kafelkiem aplikacji: niestandardowy klient OAuth nie pojawia się w launcherze aplikacji Google, więc członkowie zaczynają od strony logowania Bird lub od linku, który im podasz.

## Następne kroki

- [SSO i provisioning](/docs/knowledge-base/account-security/sso): weryfikacja domeny, test połączenia i wymuszenie SSO
- [Konfiguracja SSO z Okta](/docs/knowledge-base/account-security/sso-okta)
- [Konfiguracja SSO z Microsoft Entra ID](/docs/knowledge-base/account-security/sso-microsoft-entra-id)

## Related resources

- [Should I use an API key or an OAuth token, and how do I rotate one?](/explained/platform/api-key-or-oauth-token-and-how-do-i-rotate-one) (answer)
- [Authentication & API keys](/docs/guides/authentication) (docs)

[Get an implementation brief](/learn/workspace?topic=account-access)