OpenID Connect applikasjonsregistrering

FoxIDs OpenID Connect applikasjonsregistrering gjør det mulig å koble til en OpenID Connect basert applikasjon.

Applikasjonen din blir en Relying Party (RP), og FoxIDs fungerer som OpenID Provider (OP).

FoxIDs støtter OpenID Connect Discovery, slik at applikasjonen din kan finne OpenID Provideren.

FoxIDs støtter OpenID Connect authentication, RP-initiated logout og front-channel logout. En sesjon opprettes når brukeren autentiserer, og sesjons-id-en inngår i ID-tokenet. Sesjonen ugyldiggjøres ved logout.

FoxIDs kan vise en bekreftelsesdialog for logout avhengig av klientkonfigurasjonen og av om et ID-token inngår i logout-forespørselen.

Som standard bruker både ID-token og access token klient-id-en som audience. Standardressursen kan fjernes fra access tokenet i FoxIDs Control.

Access tokens kan også utstedes med flere audiences og dermed målrettes mot flere API-er som er definert i FoxIDs som OAuth 2.0 ressurser. Applikasjonen kan deretter kalle et API og sikre forespørselen med access tokenet i henhold til The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs støtter både klienthemmeligheter og Proof Key for Code Exchange (PKCE), og PKCE er aktivert som standard. Hvis en klient er konfigurert med både PKCE og en hemmelighet eller nøkkel, valideres begge deler. PKCE og klienthemmelighet eller nøkkel valideres ikke i implicit flow.

Standardmetoden for klientautentisering er client secret post, og den kan endres til client secret basic eller private key JWT. Klientautentiseringsmetoden none støttes sammen med PKCE.

Det kan konfigureres opptil 10 secrets og 4 keys per klient.

FoxIDs støtter OpenID Connect UserInfo endpoint.

Veiledninger:

• Koble til Tailscale

Koble FoxIDs miljøer

• Environment Link for miljøer i samme tenant.
• OpenID Connect for miljøer i samme eller ulike tenants.

Krev multi-faktor autentisering (MFA)

OpenID Connect klienten kan kreve MFA ved å inkludere urn:foxids:mfa i parameteren acr_values. Du kan kombinere den med mer spesifikke verdier som urn:foxids:link. Se be om MFA fra applikasjoner.

Parameteren acr_values kan settes i hendelsen OnRedirectToIdentityProvider i Startup.cs:

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

Se mer kode i AspNetCoreOidcAuthorizationCodeSample og Startup.cs line 141.

Konfigurasjon

Slik konfigurerer du applikasjonen din som en OpenID Connect applikasjonsregistrering, Relying Party (RP) eller klient.

Klientens FoxIDs discovery document er https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration hvis klienten er konfigurert i tenant tenant-x, miljø environment-y og med applikasjonsregistreringens klientnavn application-client1.

En klient i en applikasjonsregistrering kan støtte innlogging via flere autentiseringsmetoder ved å legge til autentiseringsmetodens navn i URL-en. For eksempel kan et autentiseringsmetodenavn som login legges til i discovery-URL-en slik: https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Ved RP-initiated logout kan autentiseringsmetodens navn utelates i URL-en hvis ID-tokenet sendes med i forespørselen.

Konfigurer Authorization Code flow for en konfidensiell klient

En konfidensiell klient er vanligvis en serverbasert webapplikasjon der webserveren lagrer klienthemmeligheten.

• Angi klientnavnet i applikasjonsregistreringens navn.
• Velg tillatte autentiseringsmetoder.
• Angi redirect-URI-er.
• Angi post-logout redirect-URI.
• Velg code som response type eller eventuelt, men ikke anbefalt, code token eller code token id_token.
• PKCE er ikke påkrevd for en konfidensiell klient, men det anbefales for å redusere replay-angrep.
• Angi en secret.

Konfigurer Authorization Code flow for en offentlig klient

En offentlig klient kan være en nettleserbasert rich client, Blazor-klient eller mobilapp. Applikasjonen bør bruke PKCE og bør ikke bruke en klienthemmelighet.

• Angi klientnavnet i applikasjonsregistreringens navn.
• Velg tillatte autentiseringsmetoder.
• Angi redirect-URI-er.
• Angi post-logout redirect-URI.
• Velg code som response type.
• Bruk PKCE, som er aktivert som standard.

Klikk Show advanced for å konfigurere tillatte CORS origins.

Konfigurer implicit flow for en offentlig klient

En offentlig klient kan være en nettleserbasert rich client. Applikasjonen bruker verken PKCE eller klienthemmelighet.

Det anbefales ikke å bruke implicit flow fordi det er usikkert.

• Angi klientnavnet i applikasjonsregistreringens navn.
• Velg tillatte autentiseringsmetoder.
• Angi redirect-URI-er.
• Angi post-logout redirect-URI.
• Velg token id_token som response type eller eventuelt bare token.
• Deaktiver PKCE.
• Ikke angi en secret.

Klient og API

Det er mulig å konfigurere både klienten og API-et, som er en OAuth 2.0 resource, i samme OpenID Connect applikasjonsregistrering. I så fall defineres både klient og API med samme navn. Du kan også konfigurere resource scopes for API-et.

Client tab

Resource tab

Resource og scopes

Et API defineres som en resource, og scopes defineres under den ressursen. Slike scopes bruker formatet ressursnavn pluss punktum pluss scope, for eksempel application-api1.read1 eller application-api1.read2.

I klientkonfigurasjonsfanen defineres scopes under feltet for ressursnavn.

I resourcekonfigurasjonsfanen defineres scopes som en liste over scope-verdier.

Scopes som er konfigurert på klienten valideres mot de scopes som finnes på API-et. Hvis klient og API er konfigurert i samme applikasjonsregistrering, legges scopes som legges til på klienten automatisk til på ressursen.

Scopes

Scopes kan konfigureres i klientkonfigurasjonsfanen. Du kan definere nye scopes og settet av claims som skal utstedes for disse scopene i listen Voluntary claims.

Du kan endre claims og implementere claim tasks med claim transforms og claim tasks.

Hvis du oppretter en ny claim, legg til claimen eller * i listen Issue claims, eller legg claimen til listen Voluntary claims og be om scopet fra applikasjonen din.

Et sett med standardscopes legges til i klientkonfigurasjonen og kan deretter endres eller slettes.

Tokenlevetid

Tokenlevetiden konfigureres for ID-token, access token og refresh token.

I dette eksemplet er hvert refresh token gyldig i 36 000 sekunder. Applikasjonen kan fortsette å fornye sesjonen med refresh tokens til den absolutte levetiden på 86 400 sekunder er nådd.