OpenID Connect Anwendungsregistrierung

FoxIDs OpenID Connect Anwendungsregistrierung ermöglicht es, eine OpenID Connect basierte Anwendung zu verbinden.

Ihre Anwendung wird zur Relying Party (RP), und FoxIDs agiert als OpenID Provider (OP).

FoxIDs unterstützt OpenID Connect Discovery, damit Ihre Anwendung den OpenID Provider entdecken kann.

FoxIDs unterstützt OpenID Connect authentication, RP-initiated logout und front-channel logout. Eine Sitzung wird erstellt, wenn sich der Benutzer authentifiziert, und die Sitzungs-ID ist im ID Token enthalten. Die Sitzung wird beim Logout ungültig.

FoxIDs kann abhängig von der Client-Konfiguration und davon, ob ein ID Token im Logout Request enthalten ist, einen Logout-Bestätigungsdialog anzeigen.

Standardmäßig verwenden sowohl ID Token als auch Access Token die Client-ID als Audience. Die Standardressource kann im Access Token in FoxIDs Control entfernt werden.

Access Tokens können außerdem mit mehreren Audiences ausgestellt werden und damit mehrere APIs ansprechen, die in FoxIDs als OAuth 2.0 Ressourcen definiert sind. Die Anwendung kann dann eine API aufrufen und den Request gemäß The OAuth 2.0 Authorization Framework: Bearer Token Usage mit dem Access Token absichern.

FoxIDs unterstützt sowohl Client Secrets als auch Proof Key for Code Exchange (PKCE), und PKCE ist standardmäßig aktiviert. Wenn ein Client sowohl mit PKCE als auch mit einem Secret oder Key konfiguriert ist, wird beides validiert. PKCE und Client Secret oder Key werden im Implicit Flow nicht validiert.

Die Standardmethode für die Client-Authentifizierung ist client secret post und kann in client secret basic oder private key JWT geändert werden. Die Client-Authentifizierungsmethode none wird zusammen mit PKCE unterstützt.

Pro Client können bis zu 10 Secrets und 4 Keys konfiguriert werden.

FoxIDs unterstützt den OpenID Connect UserInfo endpoint.

Anleitungen:

• Verbinde Tailscale

FoxIDs Umgebungen verbinden

• Environment Link für Umgebungen im selben Tenant.
• OpenID Connect für Umgebungen im selben oder in unterschiedlichen Tenants.

Multi-Faktor Authentifizierung (MFA) anfordern

Der OpenID Connect Client kann MFA anfordern, indem urn:foxids:mfa im Parameter acr_values übergeben wird. Sie können dies mit spezifischeren Werten wie urn:foxids:link kombinieren. Siehe MFA von Anwendungen anfordern.

Der Parameter acr_values kann im Event OnRedirectToIdentityProvider in Startup.cs gesetzt werden:

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

Weitere Beispiele finden Sie im AspNetCoreOidcAuthorizationCodeSample und in Startup.cs line 141.

Konfiguration

So konfigurieren Sie Ihre Anwendung als OpenID Connect Anwendungsregistrierung, Relying Party (RP) oder Client.

Das FoxIDs Discovery Document des Clients ist https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration wenn der Client im Tenant tenant-x, in der Umgebung environment-y und mit dem Anwendungsregistrierungs-Clientnamen application-client1 konfiguriert ist.

Ein Client in einer Anwendungsregistrierung kann die Anmeldung über mehrere Authentifizierungsmethoden unterstützen, indem der Name der Authentifizierungsmethode zur URL hinzugefügt wird. Zum Beispiel kann ein Authentifizierungsmethodenname wie login zur Discovery-URL hinzugefügt werden: https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Beim RP-initiated Logout kann der Name der Authentifizierungsmethode in der URL weggelassen werden, wenn das ID Token im Request enthalten ist.

Authorization Code Flow für einen vertraulichen Client konfigurieren

Ein vertraulicher Client ist typischerweise eine serverseitige Webanwendung, bei der der Webserver das Client Secret speichert.

• Geben Sie den Clientnamen im Namen der Anwendungsregistrierung an.
• Wählen Sie die zulässigen Authentifizierungsmethoden aus.
• Geben Sie die Redirect-URIs an.
• Geben Sie die Post-Logout-Redirect-URI an.
• Wählen Sie code als Response Type oder optional, aber nicht empfohlen, code token oder code token id_token.
• PKCE ist für einen vertraulichen Client nicht erforderlich, wird aber empfohlen, um Replay-Angriffe zu reduzieren.
• Geben Sie ein Secret an.

Authorization Code Flow für einen öffentlichen Client konfigurieren

Ein öffentlicher Client kann ein browserbasierter Rich Client, ein Blazor Client oder eine mobile App sein. Die Anwendung sollte PKCE verwenden und kein Client Secret verwenden.

• Geben Sie den Clientnamen im Namen der Anwendungsregistrierung an.
• Wählen Sie die zulässigen Authentifizierungsmethoden aus.
• Geben Sie die Redirect-URIs an.
• Geben Sie die Post-Logout-Redirect-URI an.
• Wählen Sie code als Response Type.
• Verwenden Sie PKCE, das standardmäßig aktiviert ist.

Klicken Sie auf Show advanced, um zulässige CORS Origins zu konfigurieren.

Implicit Flow für einen öffentlichen Client konfigurieren

Ein öffentlicher Client kann ein browserbasierter Rich Client sein. Die Anwendung verwendet weder PKCE noch ein Client Secret.

Es wird nicht empfohlen, den Implicit Flow zu verwenden, da er unsicher ist.

• Geben Sie den Clientnamen im Namen der Anwendungsregistrierung an.
• Wählen Sie die zulässigen Authentifizierungsmethoden aus.
• Geben Sie die Redirect-URIs an.
• Geben Sie die Post-Logout-Redirect-URI an.
• Wählen Sie token id_token als Response Type oder optional nur token.
• Deaktivieren Sie PKCE.
• Geben Sie kein Secret an.

Client und API

Es ist möglich, sowohl den Client als auch die API, also eine OAuth 2.0 resource, in derselben OpenID Connect Anwendungsregistrierung zu konfigurieren. In diesem Fall werden sowohl Client als auch API mit demselben Namen definiert. Sie können außerdem Resource Scopes für die API konfigurieren.

Client tab

Resource tab

Resource und Scopes

Eine API wird als Resource definiert, und Scopes werden unter dieser Resource definiert. Solche Scopes verwenden das Format Ressourcenname plus Punkt plus Scope, zum Beispiel application-api1.read1 oder application-api1.read2.

Im Client-Konfigurationsreiter werden die Scopes unter dem Feld für den Ressourcennamen definiert.

Im Resource-Konfigurationsreiter werden die Scopes als Liste von Scope-Werten definiert.

Scopes, die am Client konfiguriert sind, werden gegen die Scopes validiert, die auf der API vorhanden sind. Wenn Client und API in derselben Anwendungsregistrierung konfiguriert sind, werden Scopes, die am Client hinzugefügt werden, automatisch zur Resource hinzugefügt.

Scopes

Scopes können im Client-Konfigurationsreiter konfiguriert werden. Sie können neue Scopes und die Menge an Claims definieren, die für diese Scopes in der Liste Voluntary claims ausgegeben werden sollen.

Sie können Claims ändern und Claim Tasks mit Claim Transforms und Claim Tasks implementieren.

Wenn Sie einen neuen Claim erstellen, fügen Sie den Claim oder * zur Liste Issue claims hinzu oder fügen Sie den Claim zur Liste Voluntary claims hinzu und fordern Sie den Scope von Ihrer Anwendung an.

Ein Satz von Standard-Scopes wird der Client-Konfiguration hinzugefügt und kann danach geändert oder gelöscht werden.

Token-Lebensdauer

Die Token-Lebensdauer wird für ID Token, Access Token und Refresh Token konfiguriert.

In diesem Beispiel ist jedes Refresh Token 36.000 Sekunden gültig. Die Anwendung kann die Sitzung mit Refresh Tokens weiter verlängern, bis die absolute Lebensdauer von 86.400 Sekunden erreicht ist.