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.
Per eseguire richieste autenticate al servizio downstream, il servizio di livello intermedio deve assicurarsi 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. Per esempi, vedere anche le app di esempio che usano MSAL.
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 (SPA), è 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 dispone anche di caratteri jolly in un URL di risposta, non è possibile usare l'id_token per un flusso OBO. Un carattere jolly è un URL che termina con un carattere *. Ad esempio, se https://myapp.com/* è l'URL di risposta che l'id_token non può essere usato 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 sono riscattati da un client riservato anche se il client di origine dispone di 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.
- L'applicazione client esegue una richiesta all'API A con il token A, con un'attestazione
auddell'API A. - 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.
- 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.
- Il token B viene impostato dall'API A nell'intestazione dell'autorizzazione della richiesta all'API B.
- 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 Ottenere il 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
NON inviare i token di accesso rilasciati al livello intermedio a posizioni che non appartengono al gruppo di destinatari previsto per il token. I token di accesso rilasciati al livello intermedio sono destinati al solo uso di 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 lo step-up dell'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 dell'applicazione (client) che la pagina Interfaccia di amministrazione di Microsoft Entra: Registrazioni app ha assegnato all'app. |
client_secret |
Richiesto | Segreto client generato per l'app nella pagina Interfaccia di amministrazione di Microsoft Entra: Registrazioni app. È supportato anche il modello di autenticazione di base per fornire le credenziali nell'intestazione dell'autorizzazione, per RFC 6749. |
assertion |
Richiesto | Token di accesso inviato all'API di livello intermedio. Questo token deve avere un'attestazione (aud) del gruppo di destinatari dell'app che effettua questa richiesta On-Behalf-Of (l'app indicata dal campo client-id). Le applicazioni non possono riscattare un token per un'app diversa, ad esempio se un client invia a un'API un token 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=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 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 dell'applicazione (client) che la pagina Interfaccia di amministrazione di Microsoft Entra: Registrazioni app ha assegnato all'app. |
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 (aud) del gruppo di destinatari dell'app che effettua questa richiesta On-Behalf-Of (l'app indicata dal campo client-id). Le applicazioni non possono riscattare un token per un'app diversa, ad esempio se un client invia a un'API un token 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 usati nella richiesta tramite segreto condiviso, con l'eccezione del parametro client_secret che viene sostituito da due parametri: client_assertion_type e client_assertion. Il parametro client_assertion_type è impostato su urn:ietf:params:oauth:client-assertion-type:jwt-bearer e il parametro client_assertion viene 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=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 Framework di autorizzazione di OAuth 2.0: uso dei token di connessione (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 si basa sulla risorsa a cui si accede e non è correlato agli endpoint usati per richiederlo. L'API Microsoft Graph è configurata per accettare token v1.0, di conseguenza Microsoft Identity Platform genera i token di accesso v1.0 quando un client richiede i token per Microsoft Graph. Altre app possono richiedere 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 i servizi Microsoft possono usare un formato speciale che non verrà convalidato come token JWT e potrebbe anche essere crittografato per gli utenti (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 con errore
Quando si tenta di acquisire un token di accesso per l'API downstream, se questa dispone di criteri di accesso condizionale, ad esempio è impostata l'autenticazione a più fattori, l'endpoint del token restituisce una risposta di errore. 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 '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
Il servizio di livello intermedio può ora usare il token acquisito in precedenza per eseguire 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 SAML come risorsa di destinazione.
Si tratta di un'estensione non standard del flusso on-behalf-of di OAuth 2.0 che consente a un'applicazione 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 con 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 | L'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 Identità>Applicazioni>Registrazioni app e quindi selezionare il nome dell'applicazione. |
| client_secret | Obbligatorio | La chiave registrata per il servizio chiamante in Microsoft Entra ID. È necessario prendere nota di questo valore al momento della registrazione. È supportato anche il modello di autenticazione di base per fornire le credenziali nell'intestazione dell'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 esempio https:, Microsoft Entra appone il prefisso all'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 Audience risultante 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 con codifica UTF8 e 64url.
- SubjectConfirmationData per un'asserzione SAML originata da una chiamata OBO: se l'applicazione di destinazione richiede un valore
RecipientinSubjectConfirmationData, 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 valore diRecipient, 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. - Il nodo SubjectConfirmationData: il nodo non può contenere un attributo
InResponseTopoiché 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 attributoInResponseTo. - Autorizzazioni API: è necessario aggiungere le autorizzazioni API necessarie nell'applicazione di livello intermedio per consentire l'accesso all'applicazione SAML, in modo che possa richiedere un token per l'ambito
/.defaultdell'applicazione SAML. - Consenso: per ricevere un token SAML che contiene i dati utente in un flusso OAuth, è necessario aver autorizzato il consenso. Per informazioni, vedere Ottenere il 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 è token di connessione. 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>
Ottenere il consenso per l'applicazione di livello intermedio
L'obiettivo del flusso OBO garantire il consenso appropriato, in modo che l'app client possa chiamare l'app di livello intermedio e l'app di livello intermedio disponga dell'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:
.default e consenso combinato
L'applicazione di livello intermedio aggiunge il client all'elenco di applicazioni client note (knownClientApplications) nel relativo manifesto. Se una richiesta di consenso viene attivata dal client, il flusso del 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 con le applicazioni client note e .default, la schermata di consenso mostra le autorizzazioni sia del client per l'API di livello intermedio e richiederà anche le eventuali autorizzazioni necessarie per l'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ò risulta utile per semplificare le connessioni tra un client front-end e una risorsa back-end. Una risorsa può dichiarare più applicazioni pre-autorizzate (preAuthorizedApplications) nel manifesto. Qualsiasi applicazione di questo tipo può richiedere tali autorizzazioni in un flusso OBO e riceverle senza che l'utente fornisca il consenso.
Consenso amministratore
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 potrebbe esserci solo una singola associazione del client di livello intermedio e front-end. In questo scenario potrebbe risultare più semplice impostare l'applicazione come singola, senza 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.