Rejestracja aplikacji OpenID Connect

Rejestracja aplikacji OpenID Connect w FoxIDs umożliwia podłączenie aplikacji opartej na OpenID Connect.

Twoja aplikacja staje się Relying Party (RP), a FoxIDs działa jako OpenID Provider (OP).

FoxIDs obsługuje OpenID Connect Discovery, dzięki czemu aplikacja może odnaleźć OpenID Providera.

FoxIDs obsługuje OpenID Connect authentication, RP-initiated logout oraz front-channel logout. Sesja jest tworzona, gdy użytkownik się uwierzytelnia, a identyfikator sesji jest dołączany do ID token. Sesja jest unieważniana przy wylogowaniu.

FoxIDs może wyświetlić okno potwierdzenia wylogowania zależnie od konfiguracji klienta i od tego, czy żądanie wylogowania zawiera ID token.

Domyślnie zarówno ID token, jak i access token używają client ID jako audience. Domyślny zasób można usunąć z access token w FoxIDs Control.

Access tokens mogą być również wydawane z wieloma audiences, a tym samym kierowane do wielu API zdefiniowanych w FoxIDs jako zasoby OAuth 2.0. Aplikacja może wtedy wywołać API i zabezpieczyć żądanie access token zgodnie z The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs obsługuje zarówno client secrets, jak i Proof Key for Code Exchange (PKCE), a PKCE jest domyślnie włączone. Jeśli klient jest skonfigurowany zarówno z PKCE, jak i z secret lub key, walidowane są oba elementy. PKCE oraz client secret lub key nie są walidowane w implicit flow.

Domyślna metoda uwierzytelniania klienta to client secret post i można ją zmienić na client secret basic lub private key JWT. Metoda uwierzytelniania klienta none jest obsługiwana razem z PKCE.

Na klienta można skonfigurować do 10 secrets i 4 keys.

FoxIDs obsługuje endpoint OpenID Connect UserInfo endpoint.

Instrukcje:

• Połącz Tailscale

Połącz środowiska FoxIDs

• Environment Link dla środowisk w tym samym tenancie.
• OpenID Connect dla środowisk w tym samym lub różnych tenantach.

Wymaganie uwierzytelniania wieloskładnikowego (MFA)

Klient OpenID Connect może wymagać MFA przez dodanie urn:foxids:mfa do parametru acr_values. Możesz połączyć tę wartość z bardziej szczegółowymi wartościami, takimi jak urn:foxids:link. Zobacz żądanie MFA z aplikacji.

Parametr acr_values można ustawić w zdarzeniu OnRedirectToIdentityProvider w Startup.cs:

options.Events.OnRedirectToIdentityProvider = (context) =>
{
    // To require MFA
    context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
    return Task.FromResult(string.Empty);
};

Więcej kodu znajdziesz w AspNetCoreOidcAuthorizationCodeSample i Startup.cs line 141.

Konfiguracja

Tak konfigurujesz aplikację jako rejestrację aplikacji OpenID Connect, Relying Party (RP) lub klienta.

Dokument discovery klienta FoxIDs to https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration jeśli klient jest skonfigurowany w tenancie tenant-x, środowisku environment-y i z nazwą klienta application-client1.

Klient w rejestracji aplikacji może obsługiwać logowanie przez wiele metod uwierzytelniania przez dodanie nazwy metody uwierzytelniania do adresu URL. Na przykład nazwę metody uwierzytelniania, taką jak login, można dodać do adresu discovery URL w ten sposób: https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Podczas RP-initiated logout nazwa metody uwierzytelniania może zostać pominięta w adresie URL, jeśli w żądaniu jest podany ID token.

Konfigurowanie Authorization Code flow dla klienta poufnego

Klient poufny to zwykle aplikacja webowa po stronie serwera, w której serwer przechowuje client secret.

• Podaj nazwę klienta w nazwie rejestracji aplikacji.
• Wybierz dozwolone metody uwierzytelniania.
• Podaj redirect URI.
• Podaj post-logout redirect URI.
• Wybierz code jako response type albo opcjonalnie, ale niezalecane, code token lub code token id_token.
• PKCE nie jest wymagane dla klienta poufnego, ale jest zalecane, aby ograniczyć ataki typu replay.
• Podaj secret.

Konfigurowanie Authorization Code flow dla klienta publicznego

Klient publiczny może być bogatym klientem przeglądarkowym, klientem Blazor lub aplikacją mobilną. Aplikacja powinna używać PKCE i nie powinna używać client secret.

• Podaj nazwę klienta w nazwie rejestracji aplikacji.
• Wybierz dozwolone metody uwierzytelniania.
• Podaj redirect URI.
• Podaj post-logout redirect URI.
• Wybierz code jako response type.
• Używaj PKCE, które jest włączone domyślnie.

Kliknij Show advanced, aby skonfigurować dozwolone CORS origins.

Konfigurowanie implicit flow dla klienta publicznego

Klient publiczny może być bogatym klientem przeglądarkowym. Aplikacja nie używa ani PKCE, ani client secret.

Nie zaleca się używania implicit flow, ponieważ jest ono niebezpieczne.

• Podaj nazwę klienta w nazwie rejestracji aplikacji.
• Wybierz dozwolone metody uwierzytelniania.
• Podaj redirect URI.
• Podaj post-logout redirect URI.
• Wybierz token id_token jako response type albo opcjonalnie tylko token.
• Wyłącz PKCE.
• Nie podawaj secret.

Klient i API

Możliwe jest skonfigurowanie zarówno klienta, jak i API, czyli OAuth 2.0 resource, w tej samej rejestracji aplikacji OpenID Connect. W takim przypadku zarówno klient, jak i API mają tę samą nazwę. Możesz też skonfigurować resource scopes dla API.

Client tab

Resource tab

Resource i scopes

API jest definiowane jako resource, a scopes są definiowane pod tym zasobem. Takie scopes używają formatu nazwa-zasobu plus kropka plus scope, na przykład application-api1.read1 lub application-api1.read2.

W zakładce konfiguracji klienta scopes są definiowane pod polem nazwy zasobu.

W zakładce konfiguracji zasobu scopes są definiowane jako lista wartości scope.

Scopes skonfigurowane na kliencie są walidowane względem scopes istniejących w API. Jeśli klient i API są skonfigurowane w tej samej rejestracji aplikacji, scopes dodane do klienta są automatycznie dodawane do zasobu.

Scopes

Scopes można konfigurować w zakładce konfiguracji klienta. Możesz definiować nowe scopes oraz zestaw claims, które mają być wydawane dla tych scopes na liście Voluntary claims.

Możesz zmieniać claims i implementować claim tasks za pomocą claim transforms i claim tasks.

Jeśli tworzysz nowy claim, dodaj claim albo * do listy Issue claims, albo dodaj claim do listy Voluntary claims i zażądaj scope z aplikacji.

Do konfiguracji klienta dodawany jest zestaw domyślnych scopes, który następnie można zmienić lub usunąć.

Czas życia tokena

Czas życia tokena jest konfigurowany dla ID token, access token i refresh token.

W tym przykładzie każdy refresh token jest ważny przez 36 000 sekund. Aplikacja może nadal odświeżać sesję przy użyciu refresh tokens, aż do osiągnięcia bezwzględnego czasu życia 86 400 sekund.