OpenID Connect-autentiseringsmetod
En OpenID Connect-autentiseringsmetod i FoxIDs ansluter FoxIDs till en extern OpenID Provider (OP) eller Identity Provider (IdP). Den externa leverantören autentiserar användaren, medan FoxIDs fungerar som Relying Party (RP) och gör den resulterande identiteten tillgänglig för valda applikationsregistreringar.
Flera OpenID Connect-autentiseringsmetoder kan konfigureras och väljas av applikationsregistreringar. Viktiga funktioner är automatisk discovery och uppdatering av signeringsnycklar, Authorization Code Flow med PKCE, klientautentisering, konfigurerbara anspråkskällor, vidarebefordran av anspråk och anspråkstransformering.
Konfiguration
I FoxIDs Control:
- Välj den miljö som ska lita på den externa leverantören.
- Öppna Authentication och klicka på Add authentication.
- Välj Connect to OpenID Provider. Denna standardtyp visas utan att Show all options aktiveras.
- Konfigurera leverantören och klicka på Create.

Google-exempel
Detta exempel ansluter till Google med authority:
https://accounts.google.com
Konfigurera autentiseringsmetoden med:
- Ett beskrivande Name.
- Googles authority i Authority.
- Scope-värdena
profileochemail. FoxIDs inkluderar automatiskt det obligatoriska scopetopenid. - Use PKCE aktiverat.
- Den client secret som Google utfärdar.
*i Forward claims för att vidarebefordra alla mottagna anspråk.- Read claims from the ID token instead of the access token aktiverat under Show advanced.
Vilka scope-värden som krävs och om ytterligare scope-värden behövs varierar mellan leverantörer. Konfigurera endast de scope-värden som den externa leverantören kräver och som behövs för den användarinformation som applikationerna använder.
Kopiera den Redirect URL som FoxIDs visar och registrera den som en auktoriserad redirect URI hos den externa leverantören. Google utfärdar även ett client ID för OAuth-klienten. Aktivera Show advanced och ange värdet i Optional custom SP client ID. Om inget anpassat client ID har konfigurerats använder FoxIDs autentiseringsmetodens namn som client ID.

Discovery och automatiska uppdateringar
När autentiseringsmetoden skapas läser FoxIDs leverantörens OpenID Connect discovery-dokument på:
https://accounts.google.com/.well-known/openid-configuration
FoxIDs läser issuer, signeringsnycklar och de endpoints som stöds, inklusive authorization-, token-, UserInfo- och end-session-endpoints när de finns. Öppna autentiseringsmetoden igen för att granska den upptäckta issuern, nycklarna och endpoints.

FoxIDs läser discovery regelbundet och tillämpar framtida ändringar av endpoints och signeringsnycklar. Om discovery fortsätter att vara otillgänglig och de automatiska uppdateringarna stannar ska autentiseringsmetoden uppdateras i FoxIDs Control eller via Control API för att starta om dem. Uppdateringsintervallet kan ändras under Show advanced.
FoxIDs Control skapar automatiskt uppdaterade autentiseringsmetoder från discovery. Control API stöder dessutom manuellt underhållna konfigurationer där issuer, nycklar och endpoints anges direkt och discovery inte anropas.
Anspråk och vidarebefordran
Som standard validerar FoxIDs ID-token och läser användarens anspråk från den externa access token. Under Show advanced kan anspråkskällan i stället ändras till:
- Read claims from the ID token instead of the access token.
- Read claims from the UserInfo Endpoint instead of the access token or ID token.
UserInfo-alternativet använder den externa access token för att anropa den upptäckta UserInfo-endpointen. De två alternativen kan inte väljas samtidigt i FoxIDs Control.

Autentiseringsmetoden vidarebefordrar standardanspråken och de anspråk som anges under Forward claims till applikationsregistreringar. Lägg till * för att vidarebefordra alla mottagna anspråk; detta är standard. De anspråk som överförs som standard är sub, sid, acr och amr.
Lägg till access_token för att göra den externa access token tillgänglig för applikationsregistreringar. Om den externa leverantören returnerar en refresh token ska även refresh_token läggas till för vidarebefordran. En refresh token returneras vanligtvis endast när Authorization Code Flow används tillsammans med det leverantörsspecifika scope som krävs för offlineåtkomst, till exempel offline_access.
Anspråk kan väljas, byta namn, kombineras eller ändras på andra sätt med anspråkstransformeringar och anspråksuppgifter. Ett anspråk som skapas av en transformering förblir lokalt i autentiseringsmetoden om det inte inkluderas i Forward claims eller om * används.
Klientautentisering och PKCE
Autentiseringsmetoden använder Authorization Code Flow med PKCE som standard. Standardmetoden för klientautentisering vid token-endpointen är client secret post.
Aktivera Show advanced för att välja client secret basic eller private key JWT. Med private key JWT ska klientcertifikatet importeras efter att autentiseringsmetoden har skapats och motsvarande publika nyckel registreras hos den externa leverantören.

Leverantören avgör vilka klientautentiseringsmetoder och PKCE-alternativ som stöds. Använd den starkaste konfiguration som båda parter stöder.
Profiler
Profiler gör det möjligt för en OpenID Connect-autentiseringsmetod att erbjuda alternativa inloggningsvarianter utan att hela leverantörskonfigurationen dupliceras. En profil behåller autentiseringsmetodens grundinställningar och kan:
- Lägga till leverantörsspecifika scope-värden till de scope-värden som konfigurerats för autentiseringsmetoden.
- Lägga till parametrar i authorization-begäran eller ersätta ytterligare parametrar med samma namn som konfigurerats för autentiseringsmetoden.
Öppna autentiseringsmetoden, aktivera Show advanced, välj fliken Profiles och klicka på Add Profile. Ge profilen ett beskrivande Name och ett unikt Technical name, och konfigurera sedan eventuella ytterligare scope-värden och parametrar.
Exemplet nedan lägger till prompt=login, vilket ber den externa OpenID Provider att autentisera användaren igen. Värdet custom_scope visar var ett leverantörsspecifikt scope kan läggas till. Ersätt det med ett scope som leverantören stöder eller utelämna det när inget ytterligare scope krävs.

I en applikationsregistrering är både själva autentiseringsmetoden och varje profil tillgängliga som separata val. Du kan tillåta grundmetoden, en eller flera profiler eller båda. När grundmetoden väljs tillämpas inga profilinställningar. När en profil väljs kombinerar FoxIDs dess scope-värden och ytterligare parametrar med grundkonfigurationen.
Avancerade leverantörsinställningar
Följande inställningar är tillgängliga under Show advanced:
- Optional custom SP client ID åsidosätter autentiseringsmetodens namn som används som client ID. Använd den när leverantören utfärdar eller kräver ett specifikt client ID.
- Edit issuers ersätter den issuer som hämtats från discovery med en uttrycklig lista. Detta stöder leverantörer som utfärdar token från flera issuers med samma signeringsnycklar.
*accepterar alla issuers och bör endast användas när detta förtroende är avsiktligt. Den accepterade issuern läggs till i anspråketauth_method_issuer. - Party binding pattern ändrar formatet på FoxIDs callback-URL för interoperabilitet med leverantören. FoxIDs använder som standard parentesmönstret
.../(auth-method)/...; tilde-mönstret.../~auth-method~/...och punktmönstret.../.auth-method./...stöds också. - Response type, response mode, uppdateringsintervall för discovery samt inställningar för utloggning och förtroende ger ytterligare protokollkontroll.
Issuer och signeringsnycklar som visas efter skapandet förblir skrivskyddade medan den upptäckta issuern används. Aktivera endast Edit issuers när leverantören kräver en issuer-konfiguration som skiljer sig från discovery.
Guider
- Anslut IdentityServer
- Anslut Microsoft Entra ID
- Anslut Azure AD B2C
- Anslut Amazon Cognito
- Anslut Google
- Anslut Facebook
- Anslut Signicat
- Anslut Nets eID Broker