OpenID Connect-applikationsregistrering
En FoxIDs OpenID Connect-applikationsregistrering gör det möjligt för en webb-, ensides- eller native-applikation att autentisera användare via FoxIDs och ta emot ID-token och åtkomsttoken. Applikationen är Relying Party (RP) och FoxIDs är OpenID Provider (OP).
Viktiga OpenID Connect-funktioner omfattar discovery, Authorization Code Flow, PKCE, klienthemligheter och nycklar, UserInfo-endpointen, RP-initierad utloggning och front-channel logout.
Konfiguration
I FoxIDs Control:
- Välj den miljö där applikationen ska registreras.
- Öppna Applications och klicka på Add application.
- Välj Web Application, Single Page Application eller Native Application. Dessa tre OpenID Connect-alternativ visas utan att Show all options behöver aktiveras.
- Ange ett namn och en redirect-URI, granska den genererade applikationsinformationen och klicka på Create.
- Kopiera en eventuell genererad hemlighet innan skapanderesultatet stängs. En genererad hemlighet visas endast när applikationen skapas.

Efter att applikationen har skapats klickar du på Change application för att granska eller ändra alla inställningar. Kortet för applikationstypen ger en lämplig startkonfiguration, och den resulterande OpenID Connect-klienten kan därefter anpassas.
Webbapplikation (konfidentiell klient)
Välj Web Application för en applikation som körs på en server, till exempel en ASP.NET Core-, Node.js-, Java- eller PHP-applikation. Den skapas som en konfidentiell klient med:
- Authorization Code Flow med response type
code. - En genererad klienthemlighet.
- PKCE inaktiverat som standard. Aktivera Require PKCE efter skapandet när applikationen stöder PKCE. Det rekommenderas som ytterligare skydd för auktoriseringskoden.
Ange applikationens bas-URL eller callback-URL som Redirect URI. Aktivera endast Show advanced när applikationen skapas om du behöver välja klient-ID eller konfigurera exakt matchning av redirect-URL.

Ensidesapplikation (publik klient)
Välj Single Page Application för en applikation som körs i webbläsaren, till exempel React, Angular, Vue eller Blazor WebAssembly. Den skapas som en publik klient med:
- Authorization Code Flow med response type
code. - PKCE aktiverat som standard.
- Ingen klienthemlighet.
- Redirect-URL:ens origin tillagd som tillåten CORS-origin.

Native-applikation (publik klient)
Välj Native Application för en installerad mobil- eller skrivbordsapplikation, till exempel iOS, Android, React Native, .NET MAUI eller Ionic. Den skapas som en publik klient med Authorization Code Flow, PKCE aktiverat som standard och utan klienthemlighet.
Redirect-URI:n kan använda ett applikationsspecifikt schema som myapp://callback eller en HTTPS-URI som applikationen stöder.

Redirect-URI:er och absoluta värden
Som standard är Absolute URIs inaktiverat för webb- och ensidesapplikationer. Den konfigurerade redirect-URL:en behandlas då som ett basvärde, och redirect-URL:er som börjar med detta värde accepteras.
Aktivera Show advanced och Absolute URIs om du känner till den exakta URL i applikationen som användaren ska skickas tillbaka till efter inloggning. Ange den exakta URL:en som Redirect URI. Samma inställning stöder exakta applikationsspecifika URI:er för native-applikationer.
Efter skapandet kan redirect-URI:er, post-logout-redirect-URI och tillåtna CORS-origins ändras på fliken OpenID Connect Client. Låt Show advanced vara inaktiverat om inställningen du behöver inte är avancerad.
Implicit Flow
Implicit Flow finns kvar av kompatibilitetsskäl men rekommenderas inte för nya applikationer. Använd i stället Authorization Code Flow med PKCE.
För att konfigurera en befintlig publik klient för Implicit Flow klickar du på Change application, aktiverar Show advanced, ändrar Response types till token id_token eller valfritt endast token och inaktiverar Require PKCE. Response types kan ändras i samma avancerade klientinställningar när en annan kombination som stöds behövs.

Applikationsendpoints och klientsäkerhet
Applikationsinformationen i FoxIDs Control innehåller authority, klient-ID, discovery-endpoint, authorize-endpoint och token-endpoint. Ett OpenID Connect-discoverydokument har följande form:
https://foxids.com/tenant-x/environment-y/application-client1(*)/.well-known/openid-configuration
En applikation kan tillåta inloggning via flera autentiseringsmetoder. Om en autentiseringsmetod definierar profiler kan grundmetoden och varje profil väljas oberoende av varandra. Lägg till autentiseringsmetodens namn i applikationssegmentet för att välja metod i authority-URL:en:
https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration
Vid RP-initierad utloggning kan autentiseringsmetodens namn utelämnas när ID-token ingår i begäran.
Applikationsspecifik issuer
Som standard använder token som utfärdas till applikationen miljöns issuer:
https://foxids.com/tenant-x/environment-y/
För att låta issuer matcha applikationens authority klickar du på Change application, aktiverar Show advanced och aktiverar Use matching issuer and authority with application specific issuer. Issuer blir då:
https://foxids.com/tenant-x/environment-y/application-client1(*)

Den applikationsspecifika issuer ändras när de valda autentiseringsmetoderna i authority-URL:en ändras. För API:er beror issuer därför på den anropande applikationen. Token exchange är endast möjlig mellan konfigurationer med motsvarande autentiseringsmetoder.
Klientsäkerhet
Publika klienter, inklusive ensides- och native-applikationer, kan inte lagra klientuppgifter säkert. Konfigurera dem utan klienthemlighet och använd Authorization Code Flow med PKCE.
Konfidentiella klienter autentiserar sig vid token-endpointen. Standardmetoden för klientautentisering är client secret post. Aktivera Show advanced för att ändra den till client secret basic eller private key JWT. PKCE rekommenderas också när den konfidentiella klienten stöder det. Om både PKCE och en klienthemlighet eller nyckel har konfigurerats validerar FoxIDs båda.
Klientautentiseringsmetoden none stöds med PKCE. Upp till 10 hemligheter och 4 nycklar kan konfigureras för en klient. Lagra klienthemligheter och privata nycklar säkert och rotera dem vid behov.
FoxIDs etablerar en session när användaren autentiseras och inkluderar dess sessions-ID i ID-token. Sessionen ogiltigförklaras vid utloggning. Beroende på klientkonfigurationen och om utloggningsbegäran innehåller ett ID-token kan FoxIDs visa en dialog för att bekräfta utloggningen.
Klient och API
En OpenID Connect-applikationsregistrering kan innehålla både klienten och dess OAuth 2.0-resource. Klient-ID är då även API-resursens namn.
Följande exempel konfigurerar oidc-web-app som både OpenID Connect-klient och API:
- Klicka på Change application och aktivera Show advanced.
- Ändra applikationsregistreringstypen till OpenID Connect Client and OAuth 2.0 Resource.
- Behåll Default resource 'oidc-web-app' for the application itself markerad på fliken OpenID Connect Client.
- Lägg till scopes
readochwriteunder standardresursen.

Definiera samma scopes read och write som API:t exponerar på fliken OAuth 2.0 Resource.

Resource och scopes
Ett API kan i stället registreras separat som en OAuth 2.0-resource. I detta exempel anropar klienten oidc-web-app ett separat Orders API med resursnamnet orders-api.
På klientens flik OpenID Connect Client:
- Avmarkera Default resource 'oidc-web-app' for the application itself, eftersom klienten inte fungerar som sitt eget API.
- Lägg till resursen
orders-api. - Lägg till scopes
readochwriteunder resursen.
De fullständiga scopevärden som klienten begär är orders-api:read och orders-api:write.

Definiera read och write på fliken OAuth 2.0 Resource i Orders API-applikationsregistreringen.

Scopes som en klient begär valideras mot de scopes som konfigurerats på API:t. Om klienten och API:t finns i samma applikationsregistrering läggs scopes under klientens standardresurs automatiskt till i resursen.
Som standard är klient-ID audience för både ID-token och åtkomsttoken. Konfigurerade resursscopes lägger till API-audiences i åtkomsttoken, och ett åtkomsttoken kan riktas mot flera API-resurser.
Scopes och claims
OpenID Connect-scopes konfigureras på fliken OpenID Connect Client. Standardscopes offline_access, profile, email, address och phone kan ändras eller tas bort. För varje scope styr Voluntary claims vilka claims som utfärdas när klienten begär detta scope.

Aktivera Show advanced för att konfigurera Issue claims. Lägg till ett specifikt claim eller lägg till * för att utfärda alla tillgängliga claims i åtkomsttoken. Låt Include in ID token vara inaktiverat för *. Annars kopieras alla tillgängliga claims till ID-token, vilket kan göra det mycket stort och orsaka problem i flöden där ID-token skickas vid utloggning.

Alternativt kan du lägga till ett claim i ett scopes Voluntary claims och begära detta scope från applikationen. Enskilda claims kan inkluderas i ID-token när applikationen behöver dem där. Claims kan också ändras med claim transforms och claim tasks.
Tokenlivslängd
Klicka på Change application och aktivera Show advanced för att konfigurera livslängden för auktoriseringskod, ID-token, åtkomsttoken och refresh token.

I detta exempel är varje refresh token giltigt i 36 000 sekunder. Applikationen kan fortsätta att förnya sessionen tills refresh tokens absoluta livslängd på 86 400 sekunder uppnås.
Kräv multifaktorautentisering (MFA)
En OpenID Connect-klient kan kräva MFA genom att inkludera urn:foxids:mfa i parametern acr_values. Det kan kombineras med mer specifika värden som urn:foxids:link. Se begär MFA från applikationer.
Parametern acr_values kan anges i eventet OnRedirectToIdentityProvider i Startup.cs:
options.Events.OnRedirectToIdentityProvider = (context) =>
{
context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
return Task.FromResult(string.Empty);
};
Se AspNetCoreOidcAuthorizationCodeSample och dess Startup.cs-konfiguration.
Guider
- Anslut Tailscale