OpenID Connect applikasjonsregistrering

FoxIDs OpenID Connect applikasjonsregistrering muliggjør å koble til en OpenID Connect-basert applikasjon.

Applikasjonen din vil være en relying party (RP) og FoxIDs fungerer som OpenID Provider (OP).

FoxIDs støtter OpenID Connect Discovery, slik at applikasjonen din kan oppdage OpenID Provider.

FoxIDs støtter OpenID Connect authentication (login), RP initiated logout og front channel logout. En session opprettes når brukeren autentiseres. Session ID er inkludert i ID tokenet. Sessionen blir ugyldiggjort ved logout. FoxIDs kan, avhengig av konfigurasjon, vise en logout-bekreftelsesdialog og om et ID token er inkludert i logout-requesten eller ikke.

Som standard utstedes både ID token og access token med Client ID som audience. Default resource kan fjernes i access tokenet i FoxIDs Control. Access tokens kan utstedes med en liste av audiences og dermed til flere API-er definert som OAuth 2.0 resources i FoxIDs. Applikasjonen kan så kalle et API og sikre kallet med access token i henhold til The OAuth 2.0 Authorization Framework: Bearer Token Usage.

FoxIDs støtter både client secret og Proof Key for Code Exchange (PKCE) og krever PKCE som standard. Hvis en client både har PKCE og secret/key konfigurert, valideres begge. PKCE og client secret/key valideres ikke i implicit flow.

Default client authentication method er client secret post og kan endres til client secret basic eller private key JWT. Client authentication method none støttes med PKCE.

Det kan konfigureres maks 10 secrets og 4 keys per client.

FoxIDs støtter OpenID Connect UserInfo endpoint.

How to guides:

• Koble sammen to FoxIDs miljøer i samme eller forskjellige tenants med OpenID Connect
• Koble sammen to FoxIDs miljøer i samme tenant med en Environment Link

Det anbefales å bruke OpenID Connect Authorization Code Flow med PKCE, da dette anses som en sikker flow.

Require multi-factor authentication (MFA)

OpenID Connect clienten kan kreve multi-factor authentication ved å angi verdien urn:foxids:mfa i parameteren AcrValues.

Parameteren AcrValues kan settes i OnRedirectToIdentityProvider event i Startup.cs:

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

Mer kode i AspNetCoreOidcAuthorizationCodeSample og Startup.cs line 141.

Configuration

Slik konfigurerer du applikasjonen din som OpenID Connect applikasjonsregistrering relying party (RP) / client.

FoxIDs discovery dokumentet for clienten er https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configuration hvis clienten er konfigurert i tenant tenant-x og environment environment-y med applikasjonsregistrering client navn application-client1.

En applikasjonsregistrering client kan støtte login med flere authentication methods ved å legge til authentication method-navnet i URL-en. Et authentication method navn f.eks. login kan legges til discovery URL-en, f.eks. https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Under RP initiated logout kan authentication method-navnet utelates i URL-en hvis et ID token er inkludert i requesten.

Configure Authorization Code Flow for a confidential client

En confidential client kan være en webapplikasjon hvor sikkerheten håndteres av webserveren, som også lagrer client secret.

• Angi client navn i applikasjonsregistreringens navn.
• Velg tillatte authentication methods.
• Angi redirect URIs.
• Angi post logout redirect URI.
• Velg code som response type eller valgfritt, men ikke anbefalt, code token eller code token id_token.
• PKCE er ikke nødvendig for confidential client, men anbefales for å redusere replay attacks.
• Angi en secret.

Configure Authorization Code Flow for a public client

En public client kan være en nettleserbasert rich client, en Blazor client eller en mobilapp. Applikasjonen bør bruke PKCE og ikke ha en client secret.

• Angi client navn i applikasjonsregistreringens navn.
• Velg tillatte authentication methods.
• Angi redirect URIs.
• Angi post logout redirect URI.
• Velg code som response type.
• Bruk PKCE, aktivert som standard.

Klikk "Show advanced" for å konfigurere allowed CORS origins.

Configure Implicit Code Flow for a public client

En public client kan være en webapplikasjon hvor sikkerheten håndteres av webserveren, eller en nettleserbasert rich client. Applikasjonen bruker verken PKCE eller client secret. Det anbefales ikke å bruke implicit code flow fordi det er usikkert.

• Angi client navn i applikasjonsregistreringens navn.
• Velg tillatte authentication methods.
• Angi redirect URIs.
• Angi post logout redirect URI.
• Velg token id_token som response type eller valgfritt bare token.
• Deaktiver PKCE.
• Angi ingen secret.

Client and API

Det er mulig å konfigurere både client og API (OAuth 2.0 resource) i samme OpenID Connect applikasjonsregistrering, der både client og API er definert med samme navn. Du kan også konfigurere resource scopes for API-et.

Client tab

Resource tab

Resource and Scopes

Et API defineres som en resource hvor det kan defineres scopes. Slike scopes defineres som resource name punkt scope, f.eks. application-api1.read1 eller application-api1.read2.

I client konfigurasjonsfanen defineres scopes under resource name-feltet.

I resource konfigurasjonsfanen defineres scopes som en liste over scope-verdier.

Scopes konfigurert i clienten valideres hvis scopene finnes i API-et. Når client og API er konfigurert i samme applikasjonsregistrering, legges scopes automatisk til i resource.

Scopes

Scopes kan konfigureres i client konfigurasjonsfanen. Det er mulig å definere nye scopes og et sett med claims som skal utstedes for scopene i listen Voluntary claims.

Du kan endre claims og utføre claim tasks med Claim Transforms og Claim Tasks.

Når du oppretter et nytt claim, legg til claimet eller * i listen Issue claims eller legg til claimet i Voluntary claims og be om scopet fra applikasjonen.

Et sett med default scopes legges til i client konfigurasjonen, som deretter kan endres eller slettes.

Token lifetime

Token lifetime konfigureres for ID token, access token og refresh token.

I dette eksempelet er hvert refresh token gyldig i 36 000 sekunder. Applikasjonen kan fortsette sessionen med refresh tokens til den absolutte lifetime på 86 400 sekunder er nådd.