OpenID Connect Anwendungsregistrierung

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

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

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

FoxIDs unterstützt OpenID Connect authentication (Login), RP initiated logout und front channel logout. Eine Session wird erstellt, wenn der Benutzer authentifiziert. Die Session ID ist im ID Token enthalten. Die Session wird beim Logout invalidiert. FoxIDs kann abhängig von der Konfiguration einen Logout Bestätigungsdialog anzeigen und ob ein ID Token im Logout Request enthalten ist oder nicht.

Standardmäßig werden sowohl ID Token als auch Access Token mit der Client ID als Audience ausgegeben. Die Default Resource kann im Access Token in FoxIDs Control entfernt werden. Access Tokens können mit einer Liste von Audiences ausgegeben werden und damit an mehrere APIs, die in FoxIDs als OAuth 2.0 Ressourcen definiert sind. Die Anwendung kann dann ein API aufrufen und den Aufruf mit dem Access Token gemäß The OAuth 2.0 Authorization Framework: Bearer Token Usage absichern.

FoxIDs unterstützt sowohl Client Secret als auch Proof Key for Code Exchange (PKCE) und erfordert standardmäßig PKCE. Wenn ein Client sowohl PKCE als auch Secret/Key konfiguriert hat, werden beide validiert. PKCE und Client Secret/Key werden im Implicit Flow nicht validiert.

Die Default Client Authentication Method ist client secret post und kann auf client secret basic oder private key JWT geändert werden. Client Authentication Method none wird mit PKCE unterstützt.

Es können maximal 10 Secrets und 4 Keys pro Client konfiguriert werden.

FoxIDs unterstützt den OpenID Connect UserInfo endpoint.

How to guides:

• Verbinden Sie zwei FoxIDs Umgebungen im selben oder in verschiedenen Tenants mit OpenID Connect
• Verbinden Sie zwei FoxIDs Umgebungen im selben Tenant mit einem Environment Link

Es wird empfohlen, OpenID Connect Authorization Code Flow mit PKCE zu verwenden, da dies als sicherer Flow gilt.

Require multi-factor authentication (MFA)

Der OpenID Connect Client kann Multi Factor Authentication anfordern, indem der Wert urn:foxids:mfa im Parameter AcrValues angegeben wird.

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

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

Mehr Code in AspNetCoreOidcAuthorizationCodeSample und Startup.cs line 141.

Configuration

So konfigurieren Sie Ihre Anwendung als OpenID Connect Anwendungsregistrierung Relying Party (RP) / 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 und der Umgebung environment-y mit dem Anwendungsregistrierungs Client Namen application-client1 konfiguriert ist.

Ein Anwendungsregistrierungs Client kann Login über mehrere Authentifizierungsmethoden unterstützen, indem der Name der Authentifizierungsmethode zur URL hinzugefügt wird. Ein Authentifizierungsmethoden Name z. B. login kann zur Discovery URL hinzugefügt werden, z. B. https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Während RP initiated Logout kann der Authentifizierungsmethoden Name in der URL weggelassen werden, wenn ein ID Token im Request enthalten ist.

Configure Authorization Code Flow for a confidential client

Ein confidential client kann eine Webanwendung sein, bei der die Sicherheit vom Webserver gehandhabt wird, der auch das Client Secret speichert.

• Client Namen im Anwendungsregistrierungs Namen angeben.
• Erlaubte Authentifizierungsmethoden auswählen.
• Redirect URIs angeben.
• Post Logout Redirect URI angeben.
• code als Response Type wählen oder optional, aber nicht empfohlen, code token oder code token id_token.
• PKCE ist bei confidential client nicht erforderlich, aber empfohlen, um Replay Attacks zu mitigieren.
• Ein Secret angeben.

Configure Authorization Code Flow for a public client

Ein public client kann ein browserbasierter rich client, ein Blazor client oder eine mobile App sein. Die Anwendung sollte PKCE verwenden und kein Client Secret.

• Client Namen im Anwendungsregistrierungs Namen angeben.
• Erlaubte Authentifizierungsmethoden auswählen.
• Redirect URIs angeben.
• Post Logout Redirect URI angeben.
• code als Response Type auswählen.
• PKCE verwenden, standardmäßig aktiviert.

Klicken Sie "Show advanced", um allowed CORS origins zu konfigurieren.

Configure Implicit Code Flow for a public client

Ein public client kann eine Webanwendung sein, bei der die Sicherheit vom Webserver gehandhabt wird, oder ein browserbasierter rich client. Die Anwendung verwendet weder PKCE noch Client Secret. Es wird nicht empfohlen, Implicit Code Flow zu verwenden, da es unsicher ist.

• Client Namen im Anwendungsregistrierungs Namen angeben.
• Erlaubte Authentifizierungsmethoden auswählen.
• Redirect URIs angeben.
• Post Logout Redirect URI angeben.
• token id_token als Response Type wählen oder optional nur token.
• PKCE deaktivieren.
• Kein Secret angeben.

Client and API

Es ist möglich, sowohl Client als auch API (OAuth 2.0 resource) in derselben OpenID Connect Anwendungsregistrierung zu konfigurieren, wobei sowohl Client als auch API mit demselben Namen definiert sind. Außerdem können Resource Scopes für das API konfiguriert werden.

Client tab

Resource tab

Resource and Scopes

Ein API wird als Resource definiert, unter der Scopes definiert werden können. Solche Scopes werden als Resource Name Punkt Scope definiert, z. B. application-api1.read1 oder application-api1.read2.

Im Client Konfiguration Tab sind die Scopes unter dem Resource Name Feld definiert.

Im Resource Konfiguration Tab sind die Scopes als Liste von Scope Werten definiert.

Scopes, die im Client konfiguriert sind, werden validiert, wenn die Scopes im API existieren. Wenn Client und API in derselben Anwendungsregistrierung konfiguriert sind, werden Scopes im Client automatisch zur Resource hinzugefügt.

Scopes

Scopes können im Client Konfiguration Tab konfiguriert werden. Es ist möglich, neue Scopes und einen Satz von Claims zu definieren, die für die Scopes in der Voluntary claims Liste ausgegeben werden sollen.

Sie können Claims ändern und Claim Tasks mit Claim Transforms und Claim Tasks durchführen.

Wenn Sie ein neues Claim erstellen, fügen Sie das Claim oder * zur Issue claims Liste hinzu oder fügen Sie das Claim zur Voluntary claims Liste hinzu und fordern Sie den Scope aus Ihrer Anwendung an.

Ein Satz von Default Scopes wird in der Client Konfiguration hinzugefügt, der anschließend geändert oder gelöscht werden kann.

Token lifetime

Die Token Lifetime 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 Session mit Refresh Tokens fortsetzen, bis die absolute Lifetime von 86.400 Sekunden erreicht ist.