Registrazione applicativa OpenID Connect
La registrazione applicativa OpenID Connect di FoxIDs ti consente di collegare un'applicazione basata su OpenID Connect.
La tua applicazione diventa una Relying Party (RP) e FoxIDs agisce come OpenID Provider (OP).
FoxIDs supporta OpenID Connect discovery, cosi la tua applicazione puo individuare l'OpenID Provider.
FoxIDs supporta l'autenticazione OpenID Connect, RP-initiated logout e front-channel logout. Una sessione viene stabilita quando l'utente si autentica e l'ID di sessione e incluso nell'ID token. La sessione viene invalidata al logout.
FoxIDs puo mostrare una finestra di conferma logout a seconda della configurazione del client e del fatto che una richiesta di logout includa o meno un ID token.
Per impostazione predefinita, sia l'ID token sia l'access token usano il client ID come audience. La risorsa predefinita puo essere rimossa dall'access token in FoxIDs Control.
Gli access token possono anche essere emessi con piu audience e quindi indirizzare piu API definite in FoxIDs come risorse OAuth 2.0. L'applicazione puo quindi chiamare un'API e proteggere la richiesta con l'access token.
FoxIDs supporta sia client secret sia Proof Key for Code Exchange (PKCE), e PKCE e abilitato per impostazione predefinita. Se un client e configurato sia con PKCE sia con un secret o una chiave, vengono validati entrambi. PKCE e client secret o chiave non vengono validati nel flusso implicito.
Il metodo di autenticazione client predefinito e client secret post, e puo essere cambiato in client secret basic o private key JWT. Il metodo di autenticazione client none e supportato con PKCE.
Per client possono essere configurati fino a 10 secret e 4 chiavi.
FoxIDs supporta l'endpoint OpenID Connect UserInfo.
Guide pratiche:
- Connetti Tailscale
Connettere ambienti FoxIDs
Gli ambienti FoxIDs possono essere collegati in due modi:
- Environment Link per ambienti nello stesso tenant.
- OpenID Connect per ambienti nello stesso tenant o in tenant differenti.
Scegli Environment Link quando entrambi gli ambienti sono nello stesso tenant e vuoi la configurazione piu semplice. Scegli OpenID Connect quando devi collegare tenant differenti o distribuzioni FoxIDs separate.
Richiedere l'autenticazione multifattore (MFA)
Il client OpenID Connect puo richiedere MFA includendo urn:foxids:mfa nel parametro acr_values. Puoi combinarlo con valori piu specifici come urn:foxids:link. Consulta richiedere MFA dalle applicazioni.
Il parametro acr_values puo essere impostato nell'evento OnRedirectToIdentityProvider in Startup.cs:
options.Events.OnRedirectToIdentityProvider = (context) =>
{
// To require MFA
context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
return Task.FromResult(string.Empty);
};
Vedi altro codice in AspNetCoreOidcAuthorizationCodeSample e Startup.cs line 141.
Configurazione
Come configurare la tua applicazione come registrazione applicativa OpenID Connect, Relying Party (RP) o client.
Il documento discovery FoxIDs del client e
https://foxids.com/tenant-x/environment-y/application-client1/.well-known/openid-configurationse il client e configurato nel tenanttenant-x, nell'ambienteenvironment-y, con il nome del client di registrazione applicativaapplication-client1.
Un client di registrazione applicativa puo supportare il login tramite piu metodi di autenticazione aggiungendo il nome del metodo di autenticazione all'URL. Ad esempio, un nome di metodo di autenticazione come
loginpuo essere aggiunto all'URL discovery in questo modo:https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration
Durante RP-initiated logout, il nome del metodo di autenticazione puo essere omesso nell'URL se nella richiesta viene fornito l'ID token.
Configurare Authorization Code Flow per un client confidenziale
Un client confidenziale e in genere un'applicazione web lato server in cui il server web archivia il client secret.
- Specifica il nome del client nel nome della registrazione applicativa.
- Seleziona i metodi di autenticazione consentiti.
- Specifica gli URI di redirect.
- Specifica l'URI di redirect post-logout.
- Seleziona
codecome response type oppure, facoltativamente ma non consigliato,code tokenocode token id_token. - PKCE non e richiesto per un client confidenziale, ma e consigliato per mitigare attacchi di replay.
- Specifica un secret.
Configurare Authorization Code Flow per un client pubblico
Un client pubblico puo essere un rich client basato su browser, un client Blazor o un'app mobile. L'applicazione dovrebbe usare PKCE e non dovrebbe usare un client secret.
- Specifica il nome del client nel nome della registrazione applicativa.
- Seleziona i metodi di autenticazione consentiti.
- Specifica gli URI di redirect.
- Specifica l'URI di redirect post-logout.
- Seleziona
codecome response type. - Usa PKCE, che e abilitato per impostazione predefinita.
Fai clic su Show advanced per configurare le CORS origins consentite.
Configurare Implicit Code Flow per un client pubblico
Un client pubblico puo essere un rich client basato su browser. L'applicazione non usa ne PKCE ne un client secret.
Non e consigliato usare Implicit Code Flow perche e insicuro.
- Specifica il nome del client nel nome della registrazione applicativa.
- Seleziona i metodi di autenticazione consentiti.
- Specifica gli URI di redirect.
- Specifica l'URI di redirect post-logout.
- Seleziona
token id_tokencome response type oppure, facoltativamente, solotoken. - Disabilita PKCE.
- Non specificare un secret.
Client e API
E possibile configurare sia il client sia l'API, che e una risorsa OAuth 2.0, nella stessa registrazione applicativa OpenID Connect. In tal caso sia il client sia l'API vengono definiti con lo stesso nome. Puoi anche configurare resource scopes per l'API.
Client tab
Resource tab
Resource and Scopes
Un'API viene definita come risorsa e gli scope vengono definiti sotto quella risorsa. Tali scope usano il formato nome risorsa punto scope, ad esempio application-api1.read1 o application-api1.read2.
Nel tab di configurazione client, gli scope sono definiti sotto il campo nome risorsa.
Nel tab di configurazione della risorsa, gli scope sono definiti come elenco di valori scope.
Gli scope configurati sul client vengono validati rispetto agli scope esistenti sull'API. Se client e API sono configurati nella stessa registrazione applicativa, gli scope aggiunti al client vengono automaticamente aggiunti alla risorsa.
Scope
Gli scope possono essere configurati nel tab di configurazione client. Puoi definire nuovi scope e l'insieme di claim che devono essere emessi per quegli scope nella lista Voluntary claims.
Puoi modificare i claim e implementare claim task con trasformazioni e attivita dei claim.
Se stai creando un nuovo claim, aggiungi il claim o * alla lista Issue claims, oppure aggiungi il claim alla lista Voluntary claims e richiedi lo scope dalla tua applicazione.
Un insieme di scope predefiniti viene aggiunto alla configurazione del client e puo poi essere modificato o eliminato.
Durata dei token
La durata del token viene configurata per ID token, access token e refresh token.
In questo esempio, ogni refresh token e valido per 36.000 secondi. L'applicazione puo continuare a rinnovare la sessione con refresh token finche non viene raggiunta la durata assoluta di 86.400 secondi.