Microsoft Identity Platform e flusso On-Behalf-Of di OAuth 2.0

Il flusso OBO (On-behalf-of) descrive lo scenario di un'API Web che usa un'identità diversa dalla propria per chiamare un'altra API Web. Indicato come delega in OAuth, l'intento è quello di passare l'identità e le autorizzazioni di un utente tramite la catena di richieste.

Affinché il servizio di livello intermedio esegua richieste autenticate al servizio downstream, deve proteggere un token di accesso da Microsoft Identity Platform. Usa solo ambiti delegati e non ruoli applicazione. I ruoli rimangono associati all'entità (l'utente) e non all'applicazione che opera per conto dell'utente. Ciò si verifica per impedire all'utente di ottenere l'autorizzazione per le risorse a cui non deve avere accesso.

Questo articolo descrive come programmare direttamente in base al protocollo nell'applicazione. Quando possibile, è consigliabile usare le librerie di autenticazione Microsoft (MSAL) supportate anziché acquisire i token e chiamare le API Web protette. Vedere anche le app di esempio che usano MSAL per esempi.

Limitazioni client

Se un'entità servizio ha richiesto un token solo app e l'ha inviata a un'API, tale API scambia un token che non rappresenta l'entità servizio originale. Questo perché il flusso OBO funziona solo per le entità utente. Al contrario, deve usare il flusso di credenziali client per ottenere un token solo app. Nel caso di app a pagina singola, è consigliabile passare un token di accesso a un client riservato di livello intermedio per eseguire i flussi OBO.

Se un client usa il flusso implicito per ottenere un id_token e include anche caratteri jolly in un URL di risposta, il id_token non può essere usato per un flusso OBO. Un carattere jolly è un URL che termina con un * carattere . Ad esempio, se https://myapp.com/* è l'URL di risposta non è possibile usare il id_token perché non è abbastanza specifico per identificare il client. In questo modo si impedisce l'emissione del token. Tuttavia, i token di accesso acquisiti tramite il flusso di concessione implicita vengono riscattati da un client riservato, anche se il client di avvio ha un URL di risposta con caratteri jolly registrato. Ciò è dovuto al fatto che il client riservato può identificare il client che ha acquisito il token di accesso. Il client riservato può quindi usare il token di accesso per acquisire un nuovo token di accesso per l'API downstream.

Inoltre, le applicazioni con chiavi di firma personalizzate non possono essere usate come API di livello intermedio nel flusso OBO. Sono incluse le applicazioni aziendali configurate per l'accesso Single Sign-On. Se l'API di livello intermedio usa una chiave di firma personalizzata, l'API downstream non convaliderà la firma del token di accesso passato. Ciò genera un errore perché i token firmati con una chiave controllata dal client non possono essere accettati in modo sicuro.

Diagramma del protocollo

Si supponga che l'utente abbia autenticato un'applicazione usando il flusso di concessione del codice di autorizzazione OAuth 2.0 o un altro flusso di accesso. A questo punto, l'applicazione contiene un token di accesso per l'API A (token A) con le attestazioni dell'utente e il consenso per accedere all'API Web di livello intermedio (API A). A questo punto, l'API A deve effettuare una richiesta autenticata all'API Web downstream (API B).

I passaggi che seguono costituiscono il flusso OBO e vengono spiegati con l'aiuto del diagramma seguente.

Shows the OAuth2.0 On-Behalf-Of flow

  1. L'applicazione client esegue una richiesta all'API A con il token A, con un'attestazione aud dell'API A.
  2. L'API A esegue l'autenticazione all'endpoint di rilascio del token di Microsoft Identity Platform e richiede un token per accedere all'API B.
  3. L'endpoint di rilascio del token di Microsoft Identity Platform convalida le credenziali dell'API A con il token A ed emette il token di accesso per l'API B (token B) all'API A.
  4. Il token B viene impostato dall'API A nell'intestazione dell'autorizzazione della richiesta all'API B.
  5. I dati della risorsa protetta vengono restituiti dall'API B all'API A e quindi al client.

In questo scenario, il servizio di livello intermedio non ha alcuna interazione dell'utente per ottenere il consenso dell'utente per accedere all'API downstream. Di conseguenza, l'opzione per concedere l'accesso all'API downstream viene presentata in anticipo come parte del passaggio di consenso durante l'autenticazione. Per informazioni su come implementare questa funzionalità nell'app, vedere Acquisizione del consenso per l'applicazione di livello intermedio.

Richiesta di token di accesso di livello intermedio

Per richiedere un token di accesso, eseguire una richiesta HTTP POST all'endpoint del token di Microsoft Identity Platform specifico del tenant con i parametri seguenti.

https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token

Avviso

DO NOT send access tokens that were issued to the middle tier to any other party. I token di accesso rilasciati al livello intermedio sono destinati all'uso solo da tale livello intermedio.

I rischi per la sicurezza dell'inoltro dei token di accesso da una risorsa di livello intermedio a un client (anziché ottenere i token di accesso stessi) includono:

  • Maggiore rischio di intercettazione dei token sui canali SSL/TLS compromessi.
  • Impossibilità di soddisfare l'associazione di token e gli scenari di accesso condizionale che richiedono l'attestazione (ad esempio, MFA, frequenza di accesso).
  • Incompatibilità con i criteri basati su dispositivi configurati dall'amministratore (ad esempio, MDM, criteri basati sulla posizione).

L'applicazione client può scegliere di essere protetta da un segreto condiviso oppure da un certificato.

Primo caso: richiesta del token di accesso con un segreto condiviso

Quando viene usato un segreto condiviso, una richiesta di token di accesso da servizio a servizio contiene i parametri seguenti:

Parametro Tipo Descrizione
grant_type Richiesto Tipo della richiesta di token. Per una richiesta con un token JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer.
client_id Richiesto ID applicazione (client) assegnato all'app dall'interfaccia di amministrazione di Microsoft Entra- Registrazioni app pagina.
client_secret Richiesto Segreto client generato per l'app nell'interfaccia di amministrazione di Microsoft Entra - Registrazioni app pagina. È supportato anche il modello di autenticazione di base per fornire le credenziali nell'intestazione Autorizzazione, per RFC 6749 .
assertion Richiesto Token di accesso inviato all'API di livello intermedio. Questo token deve avere un'attestazione di destinatari (aud) dell'app che effettua questa richiesta OBO (l'app indicata dal client-id campo). Le applicazioni non possono riscattare un token per un'app diversa, ad esempio se un client invia un token API destinato a Microsoft Graph, l'API non può riscattarla usando OBO. Deve invece rifiutare il token.
scope Richiesto Elenco di ambiti separato da spazi per la richiesta di token. Per altre informazioni, vedere Scopes (Ambiti).
requested_token_use Richiesto Specifica la modalità di elaborazione della richiesta. Nel flusso OBO il valore deve essere impostato su on_behalf_of.

Esempio

La richiesta HTTP POST seguente richiede un token di accesso e un token di aggiornamento con ambito user.read per l'API Web https://graph.microsoft.com. La richiesta viene firmata con il segreto client e viene effettuata da un client riservato.

//line breaks for legibility only
    
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
    
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
client_id=535fb089-9ff3-47b6-9bfb-4f1264799865
&client_secret=sampleCredentia1s
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiIyO{a lot of characters here}
&scope=https://graph.microsoft.com/user.read+offline_access
&requested_token_use=on_behalf_of

Secondo caso: richiesta del token di accesso con un certificato

Una richiesta di token di accesso da servizio a servizio con un certificato contiene i parametri seguenti oltre ai parametri dell'esempio precedente:

Parametro Tipo Descrizione
grant_type Richiesto Il tipo di richiesta del token. Per una richiesta con un token JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer.
client_id Richiesto ID applicazione (client) assegnato all'app dall'interfaccia di amministrazione di Microsoft Entra- Registrazioni app pagina.
client_assertion_type Richiesto Il valore deve essere urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
client_assertion Richiesto Asserzione (token Web JSON) che devi creare e firmare con il certificato registrato come credenziali per l'applicazione. Per informazioni sulla registrazione del certificato e il formato dell'asserzione, vedere le credenziali del certificato.
assertion Richiesto Token di accesso inviato all'API di livello intermedio. Questo token deve avere un'attestazione di destinatari (aud) dell'app che effettua questa richiesta OBO (l'app indicata dal client-id campo). Le applicazioni non possono riscattare un token per un'app diversa, ad esempio se un client invia un token API destinato a MS Graph, l'API non può riscattarla usando OBO. Deve invece rifiutare il token.
requested_token_use Richiesto Specifica la modalità di elaborazione della richiesta. Nel flusso OBO il valore deve essere impostato su on_behalf_of.
scope Richiesto Un elenco di ambiti separati da spazi per la richiesta di token. Per altre informazioni, vedere Scopes (Ambiti).

Si noti che i parametri sono quasi uguali a quelli della richiesta tramite segreto condiviso, ad eccezione del fatto che il client_secret parametro viene sostituito da due parametri: a client_assertion_type e client_assertion. Il client_assertion_type parametro è impostato su urn:ietf:params:oauth:client-assertion-type:jwt-bearer e il client_assertion parametro è impostato sul token JWT firmato con la chiave privata del certificato.

Esempio

La richiesta HTTP POST seguente richiede un token di accesso con ambito user.read per l'API Web https://graph.microsoft.com con un certificato. La richiesta viene firmata con il segreto client e viene effettuata da un client riservato.

// line breaks for legibility only
    
POST /oauth2/v2.0/token HTTP/1.1
Host: login.microsoftonline.com/<tenant>
Content-Type: application/x-www-form-urlencoded
    
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer
&client_id=625391af-c675-43e5-8e44-edd3e30ceb15
&client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3Aclient-assertion-type%3Ajwt-bearer
&client_assertion=eyJhbGciOiJSUzI1NiIsIng1dCI6Imd4OHRHeXN5amNScUtqRlBuZDdSRnd2d1pJMCJ9.eyJ{a lot of characters here}
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiO{a lot of characters here}
&requested_token_use=on_behalf_of
&scope=https://graph.microsoft.com/user.read+offline_access

Risposta del token di accesso di livello intermedio

Una risposta di esito positivo è una risposta OAuth 2.0 JSON con i parametri seguenti.

Parametro Descrizione
token_type Indica il valore del tipo di token. L'unico tipo supportato da Microsoft Identity Platform è Bearer. Per altre informazioni sui token di connessione, vedere OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750).
scope Ambito di accesso concesso nel token.
expires_in Intervallo di tempo, in secondi, durante il quale il token di accesso è valido.
access_token Token di accesso richiesto. Il servizio chiamante può usare questo token per l'autenticazione nel servizio ricevente.
refresh_token Token di aggiornamento per il token di accesso richiesto. Il servizio chiamante può usare questo token per richiedere un altro token di accesso dopo la scadenza del token di accesso corrente. Il token di aggiornamento viene fornito solo se è stato richiesto l'ambito offline_access.

Esempio di risposta di esito positivo

L'esempio seguente mostra una risposta corretta a una richiesta di token di accesso per l'API Web https://graph.microsoft.com. La risposta contiene un token di accesso e un token di aggiornamento e viene firmato con la chiave privata del certificato.

{
    "token_type": "Bearer",
    "scope": "https://graph.microsoft.com/user.read",
    "expires_in": 3269,
    "ext_expires_in": 0,
    "access_token": "eyJ0eXAiOiJKV1QiLCJub25jZSI6IkFRQUJBQUFBQUFCbmZpRy1tQTZOVGFlN0NkV1c3UWZkQ0NDYy0tY0hGa18wZE50MVEtc2loVzRMd2RwQVZISGpnTVdQZ0tQeVJIaGlDbUN2NkdyMEpmYmRfY1RmMUFxU21TcFJkVXVydVJqX3Nqd0JoN211eHlBQSIsImFsZyI6IlJTMjU2IiwieDV0IjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIiwia2lkIjoiejAzOXpkc0Z1aXpwQmZCVksxVG4yNVFIWU8wIn0.eyJhdWQiOiJodHRwczovL2dyYXBoLm1pY3Jvc29mdC5jb20iLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC83MmY5ODhiZi04NmYxLTQxYWYtOTFhYi0yZDdjZDAxMWRiNDcvIiwiaWF0IjoxNDkzOTMwMzA1LCJuYmYiOjE0OTM5MzAzMDUsImV4cCI6MTQ5MzkzMzg3NSwiYWNyIjoiMCIsImFpbyI6IkFTUUEyLzhEQUFBQU9KYnFFWlRNTnEyZFcxYXpKN1RZMDlYeDdOT29EMkJEUlRWMXJ3b2ZRc1k9IiwiYW1yIjpbInB3ZCJdLCJhcHBfZGlzcGxheW5hbWUiOiJUb2RvRG90bmV0T2JvIiwiYXBwaWQiOiIyODQ2ZjcxYi1hN2E0LTQ5ODctYmFiMy03NjAwMzViMmYzODkiLCJhcHBpZGFjciI6IjEiLCJmYW1pbHlfbmFtZSI6IkNhbnVtYWxsYSIsImdpdmVuX25hbWUiOiJOYXZ5YSIsImlwYWRkciI6IjE2Ny4yMjAuMC4xOTkiLCJuYW1lIjoiTmF2eWEgQ2FudW1hbGxhIiwib2lkIjoiZDVlOTc5YzctM2QyZC00MmFmLThmMzAtNzI3ZGQ0YzJkMzgzIiwib25wcmVtX3NpZCI6IlMtMS01LTIxLTIxMjc1MjExODQtMTYwNDAxMjkyMC0xODg3OTI3NTI3LTI2MTE4NDg0IiwicGxhdGYiOiIxNCIsInB1aWQiOiIxMDAzM0ZGRkEwNkQxN0M5Iiwic2NwIjoiVXNlci5SZWFkIiwic3ViIjoibWtMMHBiLXlpMXQ1ckRGd2JTZ1JvTWxrZE52b3UzSjNWNm84UFE3alVCRSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInVuaXF1ZV9uYW1lIjoibmFjYW51bWFAbWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hY2FudW1hQG1pY3Jvc29mdC5jb20iLCJ1dGkiOiJWR1ItdmtEZlBFQ2M1dWFDaENRSkFBIiwidmVyIjoiMS4wIn0.cubh1L2VtruiiwF8ut1m9uNBmnUJeYx4x0G30F7CqSpzHj1Sv5DCgNZXyUz3pEiz77G8IfOF0_U5A_02k-xzwdYvtJUYGH3bFISzdqymiEGmdfCIRKl9KMeoo2llGv0ScCniIhr2U1yxTIkIpp092xcdaDt-2_2q_ql1Ha_HtjvTV1f9XR3t7_Id9bR5BqwVX5zPO7JMYDVhUZRx08eqZcC-F3wi0xd_5ND_mavMuxe2wrpF-EZviO3yg0QVRr59tE3AoWl8lSGpVc97vvRCnp4WVRk26jJhYXFPsdk4yWqOKZqzr3IFGyD08WizD_vPSrXcCPbZP3XWaoTUKZSNJg",
    "refresh_token": "OAQABAAAAAABnfiG-mA6NTae7CdWW7QfdAALzDWjw6qSn4GUDfxWzJDZ6lk9qRw4An{a lot of characters here}"
}

Questo token di accesso è un token in formato v1.0 per Microsoft Graph. Questo perché il formato del token è basato sulla risorsa a cui si accede e non è correlato agli endpoint usati per richiederlo. Microsoft Graph è configurato per accettare token v1.0, quindi Microsoft Identity Platform produce token di accesso v1.0 quando un client richiede token per Microsoft Graph. Altre app possono indicare che vogliono token in formato v2.0, token in formato v1.0 o anche formati di token proprietari o crittografati. Entrambi gli endpoint v1.0 e v2.0 possono generare entrambi i formati di token. In questo modo, la risorsa può sempre ottenere il formato corretto del token indipendentemente dalla modalità o dalla posizione in cui il token viene richiesto dal client.

Avviso

Non tentare di convalidare o leggere i token per qualsiasi API di cui non si è proprietari, inclusi i token in questo esempio, nel codice. I token per servizi Microsoft possono usare un formato speciale che non verrà convalidato come token JWT e potrebbe anche essere crittografato per gli utenti consumer (account Microsoft). Durante la lettura dei token è uno strumento utile per il debug e l'apprendimento, non assumere dipendenze da questo nel codice o presupporre specifiche sui token che non sono per un'API che si controlla.

Esempio di risposta con errore

Quando si tenta di acquisire un token di accesso per l'API downstream, viene restituita una risposta di errore dall'endpoint del token, se l'API downstream ha un criterio di accesso condizionale (ad esempio l'autenticazione a più fattori). Il servizio di livello intermedio segnala l'errore all'applicazione client in modo che questa possa fornire l'interazione dell'utente per soddisfare i criteri di accesso condizionale.

Per restituire questo errore al client, il servizio di livello intermedio risponde con HTTP 401 Non autorizzato e con un'intestazione HTTP WWW-Authenticate contenente l'errore e la richiesta di attestazione. Il client deve analizzare questa intestazione e acquisire un nuovo token dall'autorità emittente del token, presentando la richiesta di attestazioni, se presente. I client non devono riprovare ad accedere al servizio di livello intermedio usando un token di accesso memorizzato nella cache.

{
    "error":"interaction_required",
    "error_description":"AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multifactor authentication to access 'bf8d80f9-9098-4972-b203-500f535113b1'.\r\nTrace ID: b72a68c3-0926-4b8e-bc35-3150069c2800\r\nCorrelation ID: 73d656cf-54b1-4eb2-b429-26d8165a52d7\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"b72a68c3-0926-4b8e-bc35-3150069c2800",
    "correlation_id":"73d656cf-54b1-4eb2-b429-26d8165a52d7",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"9ab03e19-ed42-4168-b6b7-7001fb3e933a\"]}}}"
}

Usare il token di accesso per accedere alla risorsa protetta

Ora il servizio di livello intermedio può usare il token acquisito in precedenza per effettuare richieste autenticate all'API Web downstream impostando il token nell'intestazione Authorization .

Esempio

    GET /v1.0/me HTTP/1.1
    Host: graph.microsoft.com
    Authorization: Bearer eyJ0eXAiO ... 0X2tnSQLEANnSPHY0gKcgw

Asserzioni SAML ottenute con un flusso di OAuth2.0 OBO

Alcuni servizi Web di OAuth devono accedere ad altre API di servizi Web che accettano le asserzioni SAML in flussi non interattivi. Microsoft Entra ID può fornire un'asserzione SAML in risposta a un flusso On-Behalf-Of che usa un servizio Web basato su SAML come risorsa di destinazione.

Si tratta di un'estensione non standard del flusso OAuth 2.0 On-Behalf-Of che consente a un'applicazione basata su OAuth2 di accedere agli endpoint API del servizio Web che usano token SAML.

Suggerimento

Se un servizio Web protetto con SAML viene chiamato da un'applicazione Web front-end, è sufficiente chiamare l'API e avviare un flusso di autenticazione interattiva normale con la sessione esistente degli utenti. È necessario usare un flusso OBO quando una chiamata da servizio a servizio richiede un token SAML per fornire il contesto utente.

Ottenere un token SAML usando una richiesta OBO con un segreto condiviso

Una richiesta da servizio a servizio per un'asserzione SAML contiene i parametri seguenti:

Parametro Tipo Descrizione
grant_type Obbligatorio Il tipo di richiesta del token. Per una richiesta che usa un token JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer.
assertion Obbligatorio Il valore del token di accesso usato nella richiesta.
client_id Obbligatorio ID app assegnato al servizio chiamante durante la registrazione con Microsoft Entra ID. Per trovare l'ID app nell'interfaccia di amministrazione di Microsoft Entra, passare a Applicazioni> di identità>Registrazioni app e quindi selezionare il nome dell'applicazione.
client_secret Obbligatorio Chiave registrata per il servizio chiamante in Microsoft Entra ID. Questo valore deve essere annotato al momento della registrazione. È supportato anche il modello di autenticazione di base per fornire le credenziali nell'intestazione Autorizzazione, per RFC 6749 .
ambito Obbligatorio Un elenco di ambiti separati da spazi per la richiesta di token. Per altre informazioni, vedere Scopes (Ambiti). SAML non ha un concetto di ambiti, ma viene usato per identificare l'applicazione SAML di destinazione per cui si vuole ricevere un token. Per questo flusso OBO, il valore dell'ambito deve essere sempre l'ID entità SAML con /.default accodato. Ad esempio, nel caso in cui l'ID entità dell'applicazione SAML sia https://testapp.contoso.com, l'ambito richiesto deve essere https://testapp.contoso.com/.default. Nel caso in cui l'ID entità non inizi con uno schema URI, ad https:esempio , Microsoft Entra prefissi l'ID entità con spn:. In tal caso è necessario richiedere l'ambito spn:<EntityID>/.default, ad esempio spn:testapp/.default nel caso in cui l'ID entità sia testapp. Il valore di ambito richiesto qui determina l'elemento risultante Audience nel token SAML, che potrebbe essere importante per l'applicazione SAML che riceve il token.
requested_token_use necessario Specifica la modalità di elaborazione della richiesta. Nel flusso On-Behalf-Of il valore deve essere on_behalf_of.
requested_token_type Obbligatorio Specifica il tipo di token richiesto. Il valore può essere urn:ietf:params:oauth:token-type:saml2 o urn:ietf:params:oauth:token-type:saml1 a seconda dei requisiti della risorsa a cui si accede.

La risposta contiene un token SAML codificato in UTF8 e Base 64url.

  • SubjectConfirmationData per un'asserzione SAML originata da una chiamata OBO: se l'applicazione di destinazione richiede un Recipient valore in SubjectConfirmationData, il valore deve essere configurato come primo URL di risposta nonwildcard nella configurazione dell'applicazione di risorse. Poiché l'URL di risposta predefinito non viene usato per determinare il Recipient valore, potrebbe essere necessario riordinare gli URL di risposta nella configurazione dell'applicazione per assicurarsi che venga usato il primo URL di risposta nonwildcard. Per altre informazioni, vedere URL di risposta.
  • Nodo SubjectConfirmationData: il nodo non può contenere un InResponseTo attributo perché non fa parte di una risposta SAML. L'applicazione che riceve il token SAML deve essere in grado di accettare l'asserzione SAML senza un InResponseTo attributo.
  • Autorizzazioni API: è necessario aggiungere le autorizzazioni API necessarie per l'applicazione di livello intermedio per consentire l'accesso all'applicazione SAML, in modo che possa richiedere un token per l'ambito /.default dell'applicazione SAML.
  • Consenso: il consenso deve essere concesso per ricevere un token SAML contenente i dati utente in un flusso OAuth. Per informazioni, vedere Acquisizione del consenso per l'applicazione di livello intermedio.

Risposta con asserzione SAML

Parametro Descrizione
token_type Indica il valore del tipo di token. L'unico tipo supportato da Microsoft Entra ID è Bearer. Per altre informazioni sui token di connessione, vedere OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) (Framework di autorizzazione di OAuth 2.0: uso dei token di connessione - RFC 6750).
ambito Ambito di accesso concesso nel token.
expires_in Il periodo di validità del token di accesso (in secondi).
expires_on Scadenza del token di accesso. La data è rappresentata come numero di secondi da 1970-01-01T0:0:0Z UTC fino alla scadenza. Questo valore viene usato per determinare la durata dei token memorizzati nella cache.
resource L'URI dell'ID app del servizio ricevente (risorsa protetta).
access_token Il parametro che restituisce l'asserzione SAML.
token di aggiornamento Token di aggiornamento. Il servizio chiamante può usare questo token per richiedere un altro token di accesso dopo la scadenza dell'asserzione SAML corrente.
  • token_type: Bearer
  • expires_in: 3296
  • ext_expires_in: 0
  • expires_on: 1529627844
  • risorsa: https://api.contoso.com
  • access_token: <asserzione SAML>
  • issued_token_type: urn:ietf:params:oauth:token-type:saml2
  • refresh_token: <Token di aggiornamento>

L'obiettivo del flusso OBO è garantire che venga fornito il consenso appropriato in modo che l'app client possa chiamare l'app di livello intermedio e l'app di livello intermedio abbia l'autorizzazione per chiamare la risorsa back-end. A seconda dell'architettura o dell'utilizzo dell'applicazione, è consigliabile considerare quanto segue per assicurarsi che il flusso OBO sia riuscito:

L'applicazione di livello intermedio aggiunge il client all'elenco di applicazioni client note (knownClientApplications) nel manifesto. Se un prompt di consenso viene attivato dal client, il flusso di consenso è sia per se stesso che per l'applicazione di livello intermedio. In Microsoft Identity Platform questa operazione viene eseguita usando l'ambito .default. L'ambito .default è un ambito speciale usato per richiedere il consenso per accedere a tutti gli ambiti per cui l'applicazione dispone delle autorizzazioni. Ciò è utile quando l'applicazione deve accedere a più risorse, ma l'utente deve richiedere il consenso una sola volta.

Quando si attiva una schermata di consenso usando applicazioni client note e .default, nella schermata di consenso vengono visualizzate le autorizzazioni sia per il client che per l'API di livello intermedio, sia per richiedere le autorizzazioni richieste dall'API di livello intermedio. L'utente fornisce il consenso per entrambe le applicazioni e quindi il flusso OBO funziona.

Il servizio risorse (API) identificato nella richiesta deve essere l'API per cui l'applicazione client richiede un token di accesso in seguito all'accesso dell'utente. Ad esempio, scope=openid https://middle-tier-api.example.com/.default (per richiedere un token di accesso per l'API di livello intermedio) o scope=openid offline_access .default (quando una risorsa non viene identificata, per impostazione predefinita è Microsoft Graph).

Indipendentemente dall'API identificata nella richiesta di autorizzazione, la richiesta di consenso viene combinata con tutte le autorizzazioni necessarie configurate per l'app client. Sono incluse anche tutte le autorizzazioni necessarie configurate per ogni API di livello intermedio elencato nell'elenco delle autorizzazioni necessarie del client, che ha identificato il client come applicazione client nota.

Applicazioni pre-autorizzate

Le risorse possono indicare che una determinata applicazione disponga sempre dell'autorizzazione per ricevere determinati ambiti. Ciò è utile per stabilire connessioni tra un client front-end e una risorsa back-end più semplice. Una risorsa può dichiarare più applicazioni pre-autorizzate (preAuthorizedApplications) nel relativo manifesto. Qualsiasi applicazione può richiedere queste autorizzazioni in un flusso OBO e riceverle senza il consenso dell'utente.

Un amministratore del tenant può garantire che le applicazioni siano autorizzate a chiamare le API necessarie fornendo il consenso dell'amministratore per l'applicazione di livello intermedio. A tale scopo, l'amministratore può trovare l'applicazione di livello intermedio nel proprio tenant, aprire la pagina delle autorizzazioni necessarie e scegliere di concedere l'autorizzazione per l'app. Per altre informazioni sul consenso dell'amministratore, vedere la documentazione su autorizzazioni e consenso.

Uso di un'applicazione singola

In alcuni scenari, è possibile avere un'unica coppia di client front-end e di livello intermedio. In questo scenario, è possibile trovare più facilmente questa singola applicazione, negando completamente la necessità di un'applicazione di livello intermedio. Per eseguire l'autenticazione tra il front-end e l'API Web, è possibile usare i cookie, un id_token o un token di accesso richiesto per l'applicazione stessa. Quindi, richiedere il consenso da questa applicazione singola alla risorsa back-end.

Vedi anche

Altre informazioni sul protocollo OAuth 2.0 e su un altro modo per eseguire l'autenticazione da servizio a servizio usando le credenziali del client.