Condividi tramite

Flusso on-Behalf-Of di Microsoft Identity Platform e 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 con il protocollo nella tua applicazione. Quando possibile, è consigliabile usare le librerie di autenticazione Microsoft supportate (MSAL) per acquisire token e chiamare API Web protette. Vedere anche le app di esempio che usano MSAL per esempi.

Limitazioni del 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 ha 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). L'API A deve ora effettuare una richiesta autenticata all'API Web downstream (API B).

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

Mostra il flusso on-Behalf-Of OAuth2.0

  1. L'applicazione client effettua una richiesta all'API A con il token A (con un'attestazione dell'API aud A).
  2. L'API A esegue l'autenticazione all'endpoint di rilascio dei token di Microsoft Identity Platform e richiede un token per accedere all'API B.
  3. L'endpoint di rilascio dei token di Microsoft Identity Platform convalida le credenziali dell'API A insieme al token A e rilascia il token di accesso per l'API B (token B) all'API A.
  4. Il token B viene impostato dall'API A nell'intestazione di 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, effettuare un POST HTTP all'endpoint del token di Microsoft Identity Platform specifico del tenant con i parametri seguenti.

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

Avvertimento

DO NOT send access tokens that were issued to the middle tier to anywhere except the intended audience for the token.DO NOT send access token that were issued to the middle tier to anywhere except the intended audience for the token. I token di accesso rilasciati al livello intermedio sono destinati all'uso solo da tale livello intermedio per comunicare con l'endpoint del gruppo di destinatari previsto.

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).

Esistono due casi a seconda che l'applicazione client scelga di essere protetta da un segreto condiviso o da un certificato.

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

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

Parametro TIPO Descrizione
grant_type Obbligatorio Tipo di richiesta di token. Per una richiesta che usa un token JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer.
client_id Obbligatorio ID applicazione (client) assegnato alla tua app dall'interfaccia di amministrazione di Microsoft Entra - Registrazioni app.
client_secret Obbligatorio Segreto client generato per l'app nella pagina Registrazioni app dell'interfaccia di amministrazione di Microsoft Entra. È supportato anche il modello di autenticazione di base per fornire le credenziali nell'intestazione Autorizzazione, per RFC 6749 .
assertion Obbligatorio 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 Obbligatorio Elenco di ambiti separati da spazi bianchi per la richiesta di token. Per altre informazioni, vedere Ambiti.
requested_token_use Obbligatorio Specifica la modalità di elaborazione della richiesta. Nel flusso OBO il valore deve essere impostato su on_behalf_of.

Esempio

Il post HTTP seguente richiede un token di accesso e un token di aggiornamento con user.read ambito per l'API https://graph.microsoft.com Web. 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=00001111-aaaa-2222-bbbb-3333cccc4444
&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 di 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 Obbligatorio Tipo della richiesta di token. Per una richiesta che usa un token JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer.
client_id Obbligatorio ID applicazione (client) assegnato alla tua app dall'interfaccia di amministrazione di Microsoft Entra - Registrazioni app.
client_assertion_type Obbligatorio Il valore deve essere urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
client_assertion Obbligatorio Un'asserzione (un token Web JSON) che è necessario creare e firmare con il certificato registrato come credenziali per l'applicazione. Per informazioni su come registrare il certificato e il formato dell'asserzione, vedere Credenziali del certificato.
assertion Obbligatorio 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 Obbligatorio Specifica la modalità di elaborazione della richiesta. Nel flusso OBO il valore deve essere impostato su on_behalf_of.
scope Obbligatorio Elenco di ambiti separati da spazi per la richiesta di token. Per altre informazioni, vedere 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

Il post HTTP seguente richiede un token di accesso con user.read ambito per l'API https://graph.microsoft.com Web 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=11112222-bbbb-3333-cccc-4444dddd5555
&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 Periodo di tempo, espresso in secondi, per cui il token di accesso è valido.
access_token Token di accesso richiesto. Il servizio chiamante può usare questo token per eseguire l'autenticazione al 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 riuscita

L'esempio seguente mostra una risposta di esito positivo a una richiesta di un 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.

Avvertimento

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 i 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). Sebbene la lettura dei token sia uno strumento utile per il debug e l'apprendimento, è consigliabile non dipendere da questo per il codice o presupporre specifiche sui token che non sono per un'API che si controlla.

Esempio di risposta di 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 deve visualizzare questo errore all'applicazione client in modo che l'applicazione client 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 'aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb'.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: 2017-05-01 22:43:20Z",
    "error_codes":[50079],
    "timestamp":"2017-05-01 22:43:20Z",
    "trace_id":"0000aaaa-11bb-cccc-dd22-eeeeee333333",
    "correlation_id":"aaaa0000-bb11-2222-33cc-444444dddddd",
    "claims":"{\"access_token\":{\"polids\":{\"essential\":true,\"values\":[\"00aa00aa-bb11-cc22-dd33-44ee44ee44ee\"]}}}"
}

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 mediante un flusso OBO di OAuth2.0

Alcuni servizi Web basati su OAuth devono accedere ad altre API del servizio Web che accettano 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 per il flusso on-Behalf-Of OAuth 2.0 che consente a un'applicazione basata su OAuth2 di accedere agli endpoint API del servizio Web che usano token SAML.

Suggerimento

Quando si chiama un servizio Web protetto da SAML da un'applicazione Web front-end, è sufficiente chiamare l'API e avviare un normale flusso di autenticazione interattiva con la sessione esistente dell'utente. È necessario usare un flusso OBO solo 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
tipo_di_concessione Obbligatorio Tipo della richiesta di token. Per una richiesta che usa un token JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer.
asserzione Obbligatorio Valore del token di accesso usato nella richiesta.
ID cliente 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 aRegistrazioni app > e quindi selezionare il nome dell'applicazione.
segreto_cliente 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 .
scopo Obbligatorio Elenco di ambiti separati da spazi per la richiesta di token. Per altre informazioni, vedere 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.
uso_del_token_richiesto Obbligatorio Specifica la modalità di elaborazione della richiesta. Nel flusso on-Behalf-Of il valore deve essere on_behalf_of.
Tipo_di_token_richiesto 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
tipo_di_token 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).For more information about bearer tokens, see OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750).
scopo Ambito di accesso concesso nel token.
scade_in Periodo di validità del token di accesso (in secondi).
scade_il Ora di scadenza del token di accesso. La data è rappresentata come numero di secondi dal 1970-01-01T0:0:0Z UTC fino all'ora di scadenza. Questo valore viene usato per determinare la durata dei token memorizzati nella cache.
risorsa URI ID app del servizio ricevente (risorsa protetta).
token di accesso 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
  • scade_in: 3296
  • durata_estesa_scade_in: 0
  • scade_il: 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 funziona il flusso OBO.

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.

Importante

Sebbene sia valida per l'uso scope=openid https://resource/.default in flussi di consenso combinati che coinvolgono applicazioni client note, non è necessario combinare .default altri ambiti delegati come User.Read, Mail.Read, profileo User.ReadWrite.All nella stessa richiesta. Ciò genererà AADSTS70011 errori perché .default rappresenta le autorizzazioni statiche con consenso preliminare, mentre le altre richiedono il consenso utente dinamico in fase di esecuzione.

offline_access a volte viene accettato con .default per abilitare i token di aggiornamento, ma non deve essere combinato con altri ambiti delegati. In caso di dubbio, suddividere le richieste di token per evitare conflitti di tipo ambito.

Applicazioni pre-autorizzate

Le risorse possono indicare che una determinata applicazione ha sempre l'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 tenant può garantire che le applicazioni dispongano dell'autorizzazione per chiamare le API necessarie fornendo il consenso amministratore per l'applicazione di livello intermedio. A tale scopo, l'amministratore può trovare l'applicazione di livello intermedio nel tenant, aprire la pagina delle autorizzazioni necessarie e scegliere di concedere l'autorizzazione per l'app. Per altre informazioni sul consenso amministratore, vedere la documentazione relativa al consenso e alle autorizzazioni.

Uso di una singola applicazione

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 cookie, un id_token o un token di accesso richiesto per l'applicazione stessa. Richiedere quindi il consenso da questa singola applicazione alla risorsa back-end.

Vedere anche

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