Concetti relativi ad AD FS OpenID Connect/OAuth

2025-04-01
Si applica a: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Si applica ad Active Directory Federation Services (AD FS) 2016 e versioni successive

Attori di autenticazione moderni

Attore	Descrizione
Utente finale	Principale di sicurezza (utenti, applicazioni, servizi e gruppi) che accedono alla risorsa.
Cliente	La tua applicazione Web, identificata dal suo ID cliente. Il client è in genere l'entità con cui l'utente finale interagisce e il client richiede token dal server di autorizzazione.
Server di autorizzazione/Identity Provider (IdP)	Il tuo server AD FS. È responsabile della verifica dell'identità delle entità di sicurezza presenti nella directory di un'organizzazione. Rilascia i token di sicurezza (token di accesso per il portatore, token ID e token di aggiornamento) al termine dell'autenticazione di tali principali di sicurezza.
Server di risorse/Provider di risorse/Parte affidabile	Posizione in cui risiede la risorsa o i dati. Si fida del server di autorizzazione per autenticare e autorizzare il client in modo sicuro e utilizza token di accesso portatore per garantire che l'accesso a una risorsa possa essere concesso.

Il diagramma seguente fornisce la relazione più semplice tra gli attori:

Tipi di applicazione

Tipo di applicazione	Descrizione	Ruolo
Applicazione nativa	Talvolta chiamato cliente pubblico. È destinata a essere un'app client che viene eseguita su un PC o un dispositivo e con cui l'utente interagisce.	Richiede token dal server di autorizzazione (AD FS) per l'accesso utente alle risorse. Invia richieste HTTP alle risorse protette usando i token come intestazioni HTTP.
Applicazione server (app Web)	Un'applicazione Web eseguita in un server ed è accessibile agli utenti tramite un browser. Poiché è in grado di gestire il segreto client o le credenziali, viene talvolta definito client client riservato.	Richiede token dal server di autorizzazione (AD FS) per l'accesso utente alle risorse. Prima di richiedere un token, il client (app Web) deve eseguire l'autenticazione usando il segreto.
API Web	Risorsa finale a cui l'utente accede. Si consideri la nuova rappresentazione delle parti fiduciarie.	Utilizza i token di accesso al portatore ottenuti dai client.

Gruppo di applicazioni

È necessario associare un gruppo di applicazioni a ogni client OAuth nativo o app Web o a una risorsa API Web configurata con AD FS. Configurare i client in un gruppo di applicazioni per accedere alle risorse nello stesso gruppo. Un gruppo di applicazioni può avere più client e risorse.

Token di sicurezza

L'autenticazione moderna usa i tipi di token seguenti:

id_token: token JWT rilasciato dal server di autorizzazione (AD FS) e utilizzato dal client. Le attestazioni nel token ID contengono informazioni sull'utente in modo che il client possa usarlo.
access_token: token JWT rilasciato dal server di autorizzazione (AD FS) e destinato a essere utilizzato dalla risorsa. L'attestazione 'aud' o audience di questo token deve corrispondere all'identificatore della risorsa o dell'API web.
refresh_token: rilasciato da AD FS per il client da usare quando è necessario aggiornare il id_token e l'access_token. Il token è opaco per il client e utilizzato solo da AD FS.

Durata dei token di aggiornamento

accesso semplice, senza KMSI, dispositivo non registrato: AD FS applica SsoLifetime e DeviceUsageWindowInDays. Il primo token di aggiornamento ha lifetime=DeviceUsageWindowInDays o SsoLifetime, in base a quale campo è inferiore, ma non rilascia ulteriori token di aggiornamento.
accesso KMSI, EnableKmsi=true nella configurazione di AD FS e kmsi=true passati come parametro: AD FS applica KmsiLifetimeMins con DeviceUsageWindowInDays. Il primo token di aggiornamento ha lifetime=DeviceUsageWindowInDays e ogni richiesta di grant_type=refresh_token successiva ottiene un nuovo token di aggiornamento. Questo processo avviene solo con client nativi o client riservati e l'autenticazione del dispositivo.
Dispositivi registrati, autenticazione del dispositivo: AD FS usa PersistentSsoLifetimeMins e DeviceUsageWindowInDays simili a KMSI. I client nativi e riservati devono ottenere nuovi token di aggiornamento, in base all'autenticazione del dispositivo.

Per altre informazioni, vedere documentazione sull'accesso Single Sign-On di AD FS.

Ambiti

Quando si registra una risorsa in AD FS, è possibile configurare gli ambiti per consentire ad AD FS di eseguire azioni specifiche. Oltre a configurare l'ambito, è necessario inviare il valore di ambito nella richiesta di AD FS per eseguire l'azione. Ad esempio, un amministratore configura l'ambito come openid durante la registrazione delle risorse e l'applicazione (client) deve inviare il scope = openid nella richiesta di autenticazione per AD FS per rilasciare il token ID. Di seguito sono riportati i dettagli sugli ambiti disponibili in AD FS:

aza: se si usano estensioni del protocollo OAuth 2.0 per i client broker e se il parametro di ambito contiene l'ambito aza, il server rilascia un nuovo token di aggiornamento primario. Imposta il token nel campo refresh_token della risposta e imposta il refresh_token_expires_in field sulla durata del nuovo token di aggiornamento primario, se ne viene applicato uno.
openid: consente all'applicazione di richiedere l'uso del protocollo di autenticazione openid connect.
logon_cert: consente a un'applicazione di richiedere certificati di accesso che è possibile usare per accedere in modo interattivo agli utenti autenticati. Il server AD FS omette il parametro access_token dalla risposta e fornisce invece una catena di certificati CMS con codifica Base64 o una risposta PKI completa cmc. Per altre informazioni, vedere MS-OAPX: estensioni del protocollo OAuth 2.0.
user_impersonation: richiede un token di accesso per conto di da AD FS. Per informazioni dettagliate su come usare questo ambito, vedere Creare un'applicazione multilivello usando OBO (On-Behalf-Of) con OAuth con AD FS 2016.
allatclaims: consente all'applicazione di richiedere anche le attestazioni nel token di accesso da aggiungere al token ID.
vpn_cert: consente a un'applicazione di richiedere certificati VPN, che stabiliscono connessioni VPN usando l'autenticazione EAP-TLS. Questa funzionalità non è più supportata.
email: consente all'applicazione di richiedere un'attestazione di posta elettronica per l'utente connesso.
profile: consente all'applicazione di richiedere attestazioni correlate al profilo per l'utente connesso.

Richieste di rimborso

I token di sicurezza (token di accesso e ID) emessi da AD FS contengono attestazioni o asserzioni di informazioni sull'oggetto autenticato. Le applicazioni possono usare attestazioni per varie attività, tra cui:

Convalidare il token
Identificare il tenant della directory dell'utente
Visualizzare le informazioni utente
Determinare l'autorizzazione del soggetto

Le attestazioni presenti in un determinato token di sicurezza dipendono dal tipo di token, dal tipo di credenziale usato per autenticare l'utente e dalla configurazione dell'applicazione.

Flusso di autenticazione di alto livello di AD FS

Di seguito è riportato un diagramma del flusso ad alto livello.

AD FS riceve la richiesta di autenticazione dal client.
AD FS convalida l'ID client nella richiesta di autenticazione con l'ID client ottenuto durante la registrazione del client e della risorsa in AD FS. Se si usa il client riservato, AD FS convalida anche il segreto client fornito nella richiesta di autenticazione. AD FS convalida anche l'URI di reindirizzamento del client.
AD FS identifica la risorsa a cui il client vuole accedere tramite il parametro della risorsa passato nella richiesta di autenticazione. Se si usa la libreria client MSAL, il parametro della risorsa non viene inviato. L'URL della risorsa viene invece inviato come parte del parametro scope: scope = [resource url]/[scope values, ad esempio openid].

Se la risorsa non viene passata usando i parametri della risorsa o dell'ambito, AD FS usa una risorsa predefinita urn:microsoft:userinfo i cui criteri, ad esempio, MFA, rilascio o autorizzazione, non possono essere configurati.
Ad FS verifica quindi se il client dispone delle autorizzazioni per accedere alla risorsa. AD FS convalida anche se gli ambiti passati nella richiesta di autenticazione corrispondono agli ambiti configurati durante la registrazione della risorsa. Se il client non dispone delle autorizzazioni o gli ambiti corretti non vengono inviati nella richiesta di autenticazione, il flusso di autenticazione termina.
Dopo aver convalidato le autorizzazioni e gli ambiti, AD FS autentica l'utente usando il metodo di autenticazione configurato.
Se un altro metodo di autenticazione è necessario in base ai criteri di risorsa o ai criteri di autenticazione globali, AD FS attiva l'autenticazione aggiuntiva.
AD FS usa l'autenticazione a più fattori Microsoft Entra o l'autenticazione a più fattori di terze parti per eseguire l'autenticazione.
Dopo l'autenticazione dell'utente, AD FS applica le regole attestazioni . Le regole delle attestazioni determinano quali attestazioni vengono inviate alla risorsa come parte dei token di sicurezza. AD FS applica anche i criteri di controllo di accesso che confermano che l'utente soddisfi le condizioni necessarie per accedere alla risorsa.
Ad FS genera quindi l'accesso e aggiorna i token. AD FS genera anche il token ID.
AD FS riceve la richiesta di autenticazione.
Se si include il scope = allatclaims nella richiesta di autenticazione, si personalizza il token ID per includere dichiarazioni nel token di accesso in base alle regole di dichiarazione definite.
Dopo aver generato e personalizzato i token necessari, AD FS risponde al client e include i token. La risposta del token ID è inclusa nella risposta solo se la richiesta di autenticazione include scope = openid. Il client può sempre ottenere il token ID dopo l'autenticazione usando l'endpoint del token.

Tipi di librerie

Usare due tipi di librerie con AD FS:

librerie client: i client nativi e le app server usano librerie client per ottenere i token di accesso per chiamare una risorsa, ad esempio un'API Web. Microsoft Authentication Library (MSAL) è la libreria client più recente e consigliata quando si usa AD FS 2019.
librerie di middleware del server: le app Web usano le librerie di middleware del server per l'accesso degli utenti. Le API Web usano librerie middleware server per convalidare i token inviati da client nativi o da altri server. Open Web Interface for .NET (OWIN) è la libreria middleware consigliata.

Personalizzare il token ID (attestazioni aggiuntive nel token ID)

In alcuni scenari, è possibile che il client dell'app Web richieda attestazioni aggiuntive in un token ID per facilitare la funzionalità. Configurare attestazioni aggiuntive in un token ID usando una delle opzioni seguenti:

opzione 1: Usare questa opzione quando si dispone di un client pubblico e l'app Web non dispone di una risorsa a cui sta tentando di accedere. Questa opzione richiede:

response_mode è impostato come form_post
L'identificatore della relying party (identificatore API Web) corrisponde all'identificatore client

Diagramma dell'opzione di personalizzazione del token di AD FS 1.

opzione 2: Usare questa opzione quando l'applicazione web ha una risorsa a cui sta tentando di accedere e deve passare attestazioni aggiuntive tramite il token ID. È possibile usare client pubblici e riservati. Questa opzione richiede:

response_mode è impostato come form_post
KB4019472 è installato nei server AD FS
L'ambito allatclaims viene assegnato alla coppia client - RP. È possibile assegnare l'ambito usando il Grant-ADFSApplicationPermission. Usare Set-AdfsApplicationPermission se è già stato concesso una volta. Il cmdlet di PowerShell è indicato nell'esempio seguente:
```
Grant-AdfsApplicationPermission -ClientRoleIdentifier "https://my/privateclient" -ServerRoleIdentifier "https://rp/fedpassive" -ScopeNames "allatclaims","openid"
```

Diagramma opzione di personalizzazione del token due di AD FS.

Per comprendere al meglio come configurare un'applicazione web in AD FS per ottenere un token d'ID personalizzato, vedere Token ID personalizzati in AD FS 2016 o versioni successive.

Disconnesso singolo

La disconnessione singola termina tutte le sessioni client che usano l'ID della sessione. AD FS 2016 e versioni successive supportano il logout singolo per OpenID Connect/OAuth. Per ulteriori informazioni, vedere disconnessione singola per OpenID Connect con AD FS.

Endpoint AD FS

AD FS Punto finale	Descrizione
/autorizza	AD FS restituisce un codice di autorizzazione che è possibile usare per ottenere il token di accesso.
/token	AD FS restituisce un token di accesso che è possibile usare per accedere alla risorsa, come nell'API Web.
/informazioni utente	AD FS restituisce la dichiarazione del soggetto.
/codice dispositivo	AD FS restituisce il codice del dispositivo e il codice utente.
/logout	AD FS disconnette l'utente.
/chiavi	Chiavi pubbliche di AD FS usate per firmare le risposte.
/.well-known/openid-configuration	AD FS restituisce i metadati OAuth/OpenID Connect.

Condividi tramite