---
title: "Konfiguracja SSO z Okta"
description: "Zarejestruj połączenie SAML lub OIDC Bird w Okta, zmapuj nazwy pól Okta na nazwy Bird, wybierz format NameID i zrotuj certyfikat podpisujący."
canonical: "https://bird.com/pl-pl/dokumentacja/knowledge-base/account-security/sso-okta"
---

# Konfiguracja SSO z Okta

Ta strona opisuje część konfiguracji po stronie Okta. 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).

Okta i Bird potrzebują nawzajem swoich wartości, więc to, od czego zaczniesz, zależy od protokołu. Miej oba otwarte podczas pracy.

## SAML

Dla SAML zacznij w Bird. 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 wartości, które się pojawią, i wróć do **Supply the details**. [Konfiguracja SAML bez wartości zastępczych](/docs/knowledge-base/account-security/sso) opisuje ten proces krok po kroku.

Nazwy pól w Okta nie odpowiadają nazwom w Bird. Dwa z nich są na tyle podobne, że łatwo je pomylić, a zamiana powoduje wysłanie odpowiedzi logowania na URL, który nie może jej obsłużyć.

| W Bird, w sekcji **Register these with your identity provider** | W Okta                                                   |
| --------------------------------------------------------------- | -------------------------------------------------------- |
| Assertion Consumer Service URL                                  | Single sign-on URL                                       |
| Entity ID                                                       | Audience URI (SP Entity ID)                              |
| Sign-in URL for this connection                                 | To nie jest pole Okta. Przekaż je członkom jako zakładkę |

**Single sign-on URL** w Okta to Assertion Consumer Service URL z Bird, a nie URL logowania z Bird. Jeśli wkleisz tam URL logowania, Okta wysyła każdą odpowiedź na niewłaściwy endpoint i logowanie kończy się błędem.

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

W ustawieniu **Name ID format** aplikacji SAML wybierz `EmailAddress` i ustaw **Application username** na wartość, po której Bird ma identyfikować konta. Bird odrzuca `Unspecified` i odrzuca odpowiedź, której format NameID nie zgadza się z formatem oczekiwanym przez połączenie.

Przeczytaj [Jak identyfikowani są członkowie](/docs/knowledge-base/account-security/sso), zanim podejmiesz decyzję: identyfikator jest trwały dla każdego, kto loguje się przez to połączenie, więc nieprzezroczysty identyfikator aplikacji z adresem przesyłanym oddzielnie jako atrybut `email` jest bezpieczniejszym wyborem.

### Ważność asercji

Okta podpisuje asercje ważne od pięciu minut przed wydaniem do pięciu minut po. Bird akceptuje to okno. Nie ma tu nic do konfiguracji.

## OIDC

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

Utwórz aplikację webową OIDC w Okta i skopiuj jej client ID oraz secret do Bird, podając issuer Okta jako **Issuer**. Bird uwierzytelnia się na endpoincie tokenów za pomocą `client_secret_basic`.

Zarejestruj **Redirect URI** z Bird jako sign-in redirect URI aplikacji.

### Kafelek aplikacji Okta

Aby umożliwić członkom rozpoczęcie logowania z pulpitu Okta, ustaw:

- **Login initiated by**: Either Okta or App
- **Application visibility**: kafelek widoczny dla użytkowników
- **Login flow**: Redirect to app to initiate login (OIDC Compliant)
- **Initiate login URI**: Initiate login URI połączenia z Bird

Wybierz przepływ zgodny z OIDC. Przepływ **Send ID Token directly to app (Okta Simplified)** w Okta wysyła token do Bird zamiast przekierowywać, a Bird go nie akceptuje.

## Przypisz aplikację

Członek, który nie jest przypisany do aplikacji Bird w Okta, zostaje odrzucony przez Okta, nie przez Bird. Bird zgłasza odmowę jako pochodzącą od dostawcy tożsamości, więc sprawdź przypisania i ewentualne reguły dostępu warunkowego w Okta, zanim ponownie sprawdzisz ustawienia samego połączenia.

## Rotacja certyfikatu podpisującego

Najpierw zrotuj certyfikat w Okta, potem w Bird. Bird weryfikuje podpisy na podstawie certyfikatów przypisanych do połączenia, więc połączenie Bird zawierające tylko nowy certyfikat, podczas gdy Okta wciąż podpisuje starym, odrzuca każde logowanie do momentu aktywacji nowego certyfikatu w Okta. Odmowa przejawia się jako błąd podpisu i ustępuje, gdy obie strony się zgadzają.

## Następne kroki

- [SSO i provisioning](/docs/knowledge-base/account-security/sso): weryfikacja domeny, testowanie połączenia i wymuszanie SSO
- [Konfiguracja SSO z Google Workspace](/docs/knowledge-base/account-security/sso-google-workspace)
- [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)