Chiamate da servizio a servizio tramite l'identità utente delegato nel flusso on-behalf-of
Avviso
Questo contenuto riguarda l'endpoint di Azure AD v1.0 meno recente. Per i nuovi progetti, usare Microsoft Identity Platform.
Il flusso On-Behalf-Of (OBO) di OAuth 2.0 consente a un'applicazione che richiama un servizio o l'API Web di superare l'autenticazione utente a un altro servizio Web o API Web. Il flusso Obi propaga l'identità utente delegato e le autorizzazioni attraverso la catena di richieste. Per eseguire richieste autenticate al servizio downstream, il servizio di livello intermedio deve assicurarsi un token di accesso da Azure Active Directory (Azure AD) per conto dell'utente.
Importante
A partire da maggio 2018, un id_token
non può essere usato per il flusso On-Behalf-Of. Le applicazioni a pagina singola (Spa) devono passare il token di accesso a un client riservato di livello intermedio per eseguire i flussi OBO. Vedere limitazioni per altri dettagli sui client che possono effettuare chiamate on-behalf-of.
Diagramma del flusso on-behalf-of
Il flusso Obo inizia dopo che l'utente è stato autenticato in un'applicazione usando il flusso di concessione del codice di autorizzazione OAuth 2.0. A questo punto, l'applicazione invia un token di accesso (token A) all'API Web di livello intermedio (API A) contenente le attestazioni dell'utente e il consenso per accedere all'API A. Successivamente, l'API A esegue una richiesta autenticata all'API Web downstream (API B).
Questi passaggi costituiscono il flusso On-Behalf-Of:
- L'applicazione client esegue una richiesta all'API A con il token A.
- L'API A esegue l'autenticazione all'endpoint di rilascio del token di Azure AD e richiede un token per accedere all'API B.
- L'endpoint di rilascio del token di Azure AD convalida le credenziali dell'API A con il token A ed emette il token di accesso per l'API B (token B).
- La richiesta all'API B contiene il token B nell'intestazione di autorizzazione.
- I dati della risorsa protetta vengono restituiti dall'API B.
Nota
L'attestazione audience in un token di accesso usato per richiedere un token per un servizio downstream deve essere l'ID del servizio che effettua la richiesta OBO. Il token deve inoltre essere firmato con la chiave di firma globale di Azure Active Directory (ovvero il valore predefinito per le applicazioni registrate tramite Registrazioni app nel portale).
Registrare l'applicazione e il servizio in Azure AD
Registrare sia l'applicazione client che il servizio di livello intermedio in Azure AD.
Registrare il servizio di livello intermedio
- Accedere al portale di Azure.
- Nella barra in alto selezionare l'account e guardare nell'elenco Directory per scegliere il tenant di Active Directory per l'applicazione.
- Fare clic su Altri servizi nel riquadro a sinistra e scegliere Azure Active Directory.
- Selezionare Registrazioni app e quindi Nuova registrazione.
- Immettere un nome descrittivo per l'applicazione e selezionare il tipo di applicazione.
- In Tipi di account supportati selezionare Account in qualsiasi directory organizzativa e account Microsoft personali.
- Impostare l'URI di reindirizzamento sull'URL di base.
- Selezionare Registra per creare l'applicazione.
- Nel portale di Azure scegliere l'applicazione e selezionare Certificati e segreti.
- Selezionare Nuovo segreto client e aggiungere un segreto con una durata di uno o due anni.
- Quando si salva questa pagina, il portale di Azure consente di visualizzare il valore del segreto. Copiare e salvare il valore del segreto in un percorso sicuro.
- Creare un ambito nell'applicazione nella pagina Esporre un'API per l'app e fare clic su "Aggiungi un ambito". Il portale può richiedere anche di creare un URI ID applicazione.
Importante
Il segreto è necessario per configurare le impostazioni dell'applicazione nell'implementazione. Il valore di questo segreto non viene visualizzato neanche in questo caso e non è recuperabile con altri mezzi. Registrarlo non appena è visibile nel portale di Azure.
Registrare l'applicazione client
- Accedere al portale di Azure.
- Nella barra in alto selezionare l'account e guardare nell'elenco Directory per scegliere il tenant di Active Directory per l'applicazione.
- Fare clic su Altri servizi nel riquadro a sinistra e scegliere Azure Active Directory.
- Selezionare Registrazioni app e quindi Nuova registrazione.
- Immettere un nome descrittivo per l'applicazione e selezionare il tipo di applicazione.
- In Tipi di account supportati selezionare Account in qualsiasi directory organizzativa e account Microsoft personali.
- Impostare l'URI di reindirizzamento sull'URL di base.
- Selezionare Registra per creare l'applicazione.
- Configurare le autorizzazioni per l'applicazione. In Autorizzazioni API selezionare Aggiungi un'autorizzazione e quindi API personali.
- Digitare il nome del servizio di livello intermedio nel campo di testo.
- Scegliere Seleziona autorizzazioni e quindi selezionare l'ambito creato nell'ultimo passaggio della registrazione del livello intermedio.
Configurare applicazioni client note
In questo scenario, il servizio di livello intermedio deve ottenere il consenso dell'utente per accedere all'API downstream senza un'interazione utente. La possibilità di concedere l'accesso all'API downstream deve essere presentata in anticipo, come parte del passaggio relativo al consenso durante l'autenticazione.
Attenersi alla procedura seguente per associare in modo esplicito la registrazione dell'app client in Azure AD con la registrazione del servizio di livello intermedio. Questa operazione unisce in una singola finestra di dialogo il consenso richiesto dal livello intermedio e dal client.
- Passare alla registrazione del servizio di livello intermedio e selezionare Manifesto per aprire l'editor manifesto.
- Individuare la proprietà di matrice
knownClientApplications
e aggiungere l'ID client dell'applicazione client come elemento. - Salvare il manifesto selezionando Salva.
Richiesta del token di accesso da servizio a servizio
Per richiedere un token di accesso, eseguire una richiesta HTTP POST all'endpoint di Azure AD specifico del tenant con i parametri seguenti:
https://login.microsoftonline.com/<tenant>/oauth2/token
L'applicazione client è protetta da un segreto condiviso o 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 | obbligatorio | Il tipo di richiesta del token. Una richiesta OBO usa un token Web JSON (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 Azure AD. Per trovare l'ID app nel portale di Azure, selezionare Active Directory, scegliere la directory e quindi selezionare il nome dell'applicazione. |
client_secret | obbligatorio | La chiave registrata per il servizio chiamante in Azure AD. È necessario prendere nota di questo valore al momento della registrazione. |
resource | obbligatorio | L'URI dell'ID app del servizio ricevente (risorsa protetta). Per trovare l'URI ID app nel portale di Azure, selezionare Active Directory e scegliere la directory. Selezionare il nome dell'applicazione, scegliere Tutte le impostazioni, quindi selezionare Proprietà. |
requested_token_use | necessarie | Specifica la modalità di elaborazione della richiesta. Nel flusso on-behalf-of il valore deve essere on_behalf_of. |
scope | obbligatorio | Un elenco di ambiti separati da spazi per la richiesta di token. Per OpenID Connect, è necessario specificare l'ambito openid. |
Esempio
La richiesta HTTP POST seguente richiede un token di accesso per l'API Web https://graph.microsoft.com.
client_id
identifica il servizio che richiede il token di accesso.
// line breaks for legibility only
POST /oauth2/token HTTP/1.1
Host: login.microsoftonline.com
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_secret=0Y1W%2BY3yYb3d9N8vSjvm8WrGzVZaAaHbHHcGbcgG%2BoI%3D
&resource=https%3A%2F%2Fgraph.microsoft.com
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.ewogICJhdWQiOiAiaHR0cHM6Ly9ncmFwaC5taWNyb3NvZnQuY29tIiwKICAiaXNzIjogImh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLAogICJpYXQiOiAxNDkzNDIzMTY4LAogICJuYmYiOiAxNDkzNDIzMTY4LAogICJleHAiOiAxNDkzNDY2OTUxLAogICJhY3IiOiAiMSIsCiAgImFpbyI6ICJBU1FBMi84REFBQUE1NnZGVmp0WlNjNWdBVWwrY1Z0VFpyM0VvV2NvZEoveWV1S2ZqcTZRdC9NPSIsCiAgImFtciI6IFsKICAgICJwd2QiCiAgXSwKICAiYXBwaWQiOiAiNjI1MzkxYWYtYzY3NS00M2U1LThlNDQtZWRkM2UzMGNlYjE1IiwKICAiYXBwaWRhY3IiOiAiMSIsCiAgImVfZXhwIjogMzAyNjgzLAogICJmYW1pbHlfbmFtZSI6ICJUZXN0IiwKICAiZ2l2ZW5fbmFtZSI6ICJOYXZ5YSIsCiAgImlwYWRkciI6ICIxNjcuMjIwLjEuMTc3IiwKICAibmFtZSI6ICJOYXZ5YSBUZXN0IiwKICAib2lkIjogIjFjZDRiY2FjLWI4MDgtNDIzYS05ZTJmLTgyN2ZiYjFiYjczOSIsCiAgInBsYXRmIjogIjMiLAogICJwdWlkIjogIjEwMDMzRkZGQTEyRUQ3RkUiLAogICJzY3AiOiAiVXNlci5SZWFkIiwKICAic3ViIjogIjNKTUlaSWJlYTc1R2hfWHdDN2ZzX0JDc3kxa1l1ekZKLTUyVm1Zd0JuM3ciLAogICJ0aWQiOiAiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwKICAidW5pcXVlX25hbWUiOiAibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLAogICJ1cG4iOiAibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLAogICJ1dGkiOiAieEN3ZnpoYS1QMFdKUU9MeENHZ0tBQSIsCiAgInZlciI6ICIxLjAiCn0.cqmUVjfVbqWsxJLUI1Z4FRx1mNQAHP-L0F4EMN09r8FY9bIKeO-0q1eTdP11Nkj_k4BmtaZsTcK_mUygdMqEp9AfyVyA1HYvokcgGCW_Z6DMlVGqlIU4ssEkL9abgl1REHElPhpwBFFBBenOk9iHddD1GddTn6vJbKC3qAaNM5VarjSPu50bVvCrqKNvFixTb5bbdnSz-Qr6n6ACiEimiI1aNOPR2DeKUyWBPaQcU5EAK0ef5IsVJC1yaYDlAcUYIILMDLCD9ebjsy0t9pj_7lvjzUSrbMdSCCdzCqez_MSNxrk1Nu9AecugkBYp3UVUZOIyythVrj6-sVvLZKUutQ
&requested_token_use=on_behalf_of
&scope=openid
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:
Parametro | Tipo | Descrizione |
---|---|---|
grant_type | obbligatorio | Il tipo di richiesta del token. Una richiesta OBO usa un token di accesso JWT, il valore deve essere urn:ietf:params:oauth:grant-type:jwt-bearer. |
assertion | necessarie | Il valore del token usato nella richiesta. |
client_id | obbligatorio | L'ID app assegnato al servizio chiamante durante la registrazione con Azure AD. Per trovare l'ID app nel portale di Azure, selezionare Active Directory, scegliere la directory e quindi selezionare il nome dell'applicazione. |
client_assertion_type | obbligatorio | Il valore deve essere urn:ietf:params:oauth:client-assertion-type:jwt-bearer . |
client_assertion | obbligatorio | Un token JSON Web che viene creato e firmato con il certificato registrato come credenziale per l'applicazione. Per informazioni sul formato dell'asserzione e su come registrare il certificato, vedere Credenziali del certificato . |
resource | obbligatorio | L'URI dell'ID app del servizio ricevente (risorsa protetta). Per trovare l'URI ID app nel portale di Azure, selezionare Active Directory e scegliere la directory. Selezionare il nome dell'applicazione, scegliere Tutte le impostazioni, quindi selezionare Proprietà. |
requested_token_use | necessarie | Specifica la modalità di elaborazione della richiesta. Nel flusso on-behalf-of il valore deve essere on_behalf_of. |
scope | obbligatorio | Un elenco di ambiti separati da spazi per la richiesta di token. Per OpenID Connect, è necessario specificare l'ambito openid. |
Questi parametri sono quasi identici della richiesta tramite segreto condiviso con la differenza che il client_secret parameter
viene sostituito da due parametri: client_assertion_type
e client_assertion
.
Esempio
La richiesta HTTP POST seguente richiede un token di accesso per l'API Web https://graph.microsoft.com con un certificato.
client_id
identifica il servizio che richiede il token di accesso.
// line breaks for legibility only
POST /oauth2/token HTTP/1.1
Host: login.microsoftonline.com
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}M8U3bSUKKJDEg
&resource=https%3A%2F%2Fgraph.microsoft.com
&assertion=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2Rkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tLzE5MjNmODYyLWU2ZGMtNDFhMy04MWRhLTgwMmJhZTAwYWY2ZCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzI2MDM5Y2NlLTQ4OWQtNDAwMi04MjkzLTViMGM1MTM0ZWFjYi8iLCJpYXQiOjE0OTM0MjMxNTIsIm5iZiI6MTQ5MzQyMzE1MiwiZXhwIjoxNDkzNDY2NjUyLCJhY3IiOiIxIiwiYWlvIjoiWTJaZ1lCRFF2aTlVZEc0LzM0L3dpQndqbjhYeVp4YmR1TFhmVE1QeG8yYlN2elgreHBVQSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiJiMzE1MDA3OS03YmViLTQxN2YtYTA2YS0zZmRjNzhjMzI1NDUiLCJhcHBpZGFjciI6IjAiLCJlX2V4cCI6MzAyNDAwLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzY3AiOiJ1c2VyX2ltcGVyc29uYXRpb24iLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidmVyIjoiMS4wIn0.R-Ke-XO7lK0r5uLwxB8g5CrcPAwRln5SccJCfEjU6IUqpqcjWcDzeDdNOySiVPDU_ZU5knJmzRCF8fcjFtPsaA4R7vdIEbDuOur15FXSvE8FvVSjP_49OH6hBYqoSUAslN3FMfbO6Z8YfCIY4tSOB2I6ahQ_x4ZWFWglC3w5mK-_4iX81bqi95eV4RUKefUuHhQDXtWhrSgIEC0YiluMvA4TnaJdLq_tWXIc4_Tq_KfpkvI004ONKgU7EAMEr1wZ4aDcJV2yf22gQ1sCSig6EGSTmmzDuEPsYiyd4NhidRZJP4HiiQh-hePBQsgcSgYGvz9wC6n57ufYKh2wm_Ti3Q
&requested_token_use=on_behalf_of
&scope=openid
Risposta del token di accesso da servizio a servizio
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 Azure AD è Bearer. Per altre informazioni sui bearer token, vedere OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) (Framework di autorizzazione di OAuth 2.0: uso dei bearer token - RFC 6750). |
scope | 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 | Token di accesso richiesto. Il servizio chiamante può usare questo token per l'autenticazione nel servizio ricevente. |
id_token | Il token ID richiesto. Il servizio chiamante può usare questo token per verificare l'identità dell'utente e avviare una sessione con l'utente. |
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 di quello corrente. |
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.
{
"token_type":"Bearer",
"scope":"User.Read",
"expires_in":"43482",
"ext_expires_in":"302683",
"expires_on":"1493466951",
"not_before":"1493423168",
"resource":"https://graph.microsoft.com",
"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCIsImtpZCI6InowMzl6ZHNGdWl6cEJmQlZLMVRuMjVRSFlPMCJ9.eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0IiwiaXNzIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiLyIsImlhdCI6MTQ5MzQyMzE2OCwibmJmIjoxNDkzNDIzMTY4LCJleHAiOjE0OTM0NjY5NTEsImFjciI6IjEiLCJhaW8iOiJBU1FBMi84REFBQUE1NnZGVmp0WlNjNWdBVWwrY1Z0VFpyM0VvV2NvZEoveWV1S2ZqcTZRdC9NPSIsImFtciI6WyJwd2QiXSwiYXBwaWQiOiI2MjUzOTFhZi1jNjc1LTQzZTUtOGU0NC1lZGQzZTMwY2ViMTUiLCJhcHBpZGFjciI6IjEiLCJlX2V4cCI6MzAyNjgzLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJwdWlkIjoiMTAwMzNGRkZBMTJFRDdGRSIsInNjcCI6IlVzZXIuUmVhZCIsInN1YiI6IjNKTUlaSWJlYTc1R2hfWHdDN2ZzX0JDc3kxa1l1ekZKLTUyVm1Zd0JuM3ciLCJ0aWQiOiIyNjAzOWNjZS00ODlkLTQwMDItODI5My01YjBjNTEzNGVhY2IiLCJ1bmlxdWVfbmFtZSI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidXBuIjoibmF2eWFAZGRvYmFsaWFub3V0bG9vay5vbm1pY3Jvc29mdC5jb20iLCJ1dGkiOiJ4Q3dmemhhLVAwV0pRT0x4Q0dnS0FBIiwidmVyIjoiMS4wIn0.cqmUVjfVbqWsxJLUI1Z4FRx1mNQAHP-L0F4EMN09r8FY9bIKeO-0q1eTdP11Nkj_k4BmtaZsTcK_mUygdMqEp9AfyVyA1HYvokcgGCW_Z6DMlVGqlIU4ssEkL9abgl1REHElPhpwBFFBBenOk9iHddD1GddTn6vJbKC3qAaNM5VarjSPu50bVvCrqKNvFixTb5bbdnSz-Qr6n6ACiEimiI1aNOPR2DeKUyWBPaQcU5EAK0ef5IsVJC1yaYDlAcUYIILMDLCD9ebjsy0t9pj_7lvjzUSrbMdSCCdzCqez_MSNxrk1Nu9AecugkBYp3UVUZOIyythVrj6-sVvLZKUutQ",
"refresh_token":"AQABAAAAAABnfiG-mA6NTae7CdWW7QfdjKGu9-t1scy_TDEmLi4eLQMjJGt_nAoVu6A4oSu1KsRiz8XyQIPKQxSGfbf2FoSK-hm2K8TYzbJuswYusQpJaHUQnSqEvdaCeFuqXHBv84wjFhuanzF9dQZB_Ng5za9xKlUENrNtlq9XuLNVKzxEyeUM7JyxzdY7JiEphWImwgOYf6II316d0Z6-H3oYsFezf4Xsjz-MOBYEov0P64UaB5nJMvDyApV-NWpgklLASfNoSPGb67Bc02aFRZrm4kLk-xTl6eKE6hSo0XU2z2t70stFJDxvNQobnvNHrAmBaHWPAcC3FGwFnBOojpZB2tzG1gLEbmdROVDp8kHEYAwnRK947Py12fJNKExUdN0njmXrKxNZ_fEM33LHW1Tf4kMX_GvNmbWHtBnIyG0w5emb-b54ef5AwV5_tGUeivTCCysgucEc-S7G8Cz0xNJ_BOiM_4bAv9iFmrm9STkltpz0-Tftg8WKmaJiC0xXj6uTf4ZkX79mJJIuuM7XP4ARIcLpkktyg2Iym9jcZqymRkGH2Rm9sxBwC4eeZXM7M5a7TJ-5CqOdfuE3sBPq40RdEWMFLcrAzFvP0VDR8NKHIrPR1AcUruat9DETmTNJukdlJN3O41nWdZOVoJM-uKN3uz2wQ2Ld1z0Mb9_6YfMox9KTJNzRzcL52r4V_y3kB6ekaOZ9wQ3HxGBQ4zFt-2U0mSszIAA",
"id_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJhdWQiOiI2MjUzOTFhZi1jNjc1LTQzZTUtOGU0NC1lZGQzZTMwY2ViMTUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC8yNjAzOWNjZS00ODlkLTQwMDItODI5My01YjBjNTEzNGVhY2IvIiwiaWF0IjoxNDkzNDIzMTY4LCJuYmYiOjE0OTM0MjMxNjgsImV4cCI6MTQ5MzQ2Njk1MSwiYW1yIjpbInB3ZCJdLCJmYW1pbHlfbmFtZSI6IlRlc3QiLCJnaXZlbl9uYW1lIjoiTmF2eWEiLCJpcGFkZHIiOiIxNjcuMjIwLjEuMTc3IiwibmFtZSI6Ik5hdnlhIFRlc3QiLCJvaWQiOiIxY2Q0YmNhYy1iODA4LTQyM2EtOWUyZi04MjdmYmIxYmI3MzkiLCJwbGF0ZiI6IjMiLCJzdWIiOiJEVXpYbkdKMDJIUk0zRW5pbDFxdjZCakxTNUllQy0tQ2ZpbzRxS1MzNEc4IiwidGlkIjoiMjYwMzljY2UtNDg5ZC00MDAyLTgyOTMtNWIwYzUxMzRlYWNiIiwidW5pcXVlX25hbWUiOiJuYXZ5YUBkZG9iYWxpYW5vdXRsb29rLm9ubWljcm9zb2Z0LmNvbSIsInVwbiI6Im5hdnlhQGRkb2JhbGlhbm91dGxvb2sub25taWNyb3NvZnQuY29tIiwidXRpIjoieEN3ZnpoYS1QMFdKUU9MeENHZ0tBQSIsInZlciI6IjEuMCJ9."
}
Esempio di risposta con errore
L'endpoint del token di Azure AD restituisce una risposta di errore quando tenta di acquisire un token di accesso per un'API downstream impostata con criteri 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.
{
"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 multi-factor 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
Il servizio di livello intermedio può usare il token acquisito per eseguire richieste autenticate all'API Web downstream, impostando il token nell'intestazione Authorization
.
Esempio
GET /me?api-version=2013-11-08 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. Azure AD può fornire un'asserzione SAML in risposta a un flusso on-behalf-of che usa un servizio Web SAML come risorsa di destinazione.
Nota
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 che usa un 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 Azure AD. Per trovare l'ID app nel portale di Azure, selezionare Active Directory, scegliere la directory e quindi selezionare il nome dell'applicazione. |
client_secret | obbligatorio | La chiave registrata per il servizio chiamante in Azure AD. È necessario prendere nota di questo valore al momento della registrazione. |
resource | obbligatorio | L'URI dell'ID app del servizio ricevente (risorsa protetta). Si tratta della risorsa che rappresenta i destinatari del token SAML. Per trovare l'URI ID app nel portale di Azure, selezionare Active Directory e scegliere la directory. Selezionare il nome dell'applicazione, scegliere Tutte le impostazioni, quindi selezionare Proprietà. |
requested_token_use | necessarie | 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 Base64url.
SubjectConfirmationData per un'asserzione SAML che ha origine da una chiamata OBO: se l'applicazione di destinazione richiede un valore del destinatario in SubjectConfirmationData, nella configurazione dell'applicazione della risorsa deve essere impostato come URL di risposta senza caratteri jolly.
Nodo SubjectConfirmationData: Il nodo non può contenere un attributo InResponseTo 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 attributo InResponseTo.
Consenso: per ricevere un token SAML che contiene i dati utente in un flusso OAuth, è necessario aver autorizzato il consenso. Per informazioni sulle autorizzazioni e su come ottenere il consenso dell'amministratore, vedere Autorizzazioni e consenso nell'endpoint v1.0 di Azure Active Directory.
Risposta con asserzione SAML
Parametro | Descrizione |
---|---|
token_type | Indica il valore del tipo di token. L'unico tipo supportato da Azure AD è Bearer. Per altre informazioni sui bearer token, vedere OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC 6750) (Framework di autorizzazione di OAuth 2.0: uso dei bearer token - RFC 6750). |
scope | 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. |
refresh_token | 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>
Limitazioni client
Client pubblici con gli URL di risposta con caratteri jolly non possono utilizzare un id_token
per i flussi OBO. Tuttavia, i token di accesso acquisiti tramite il flusso di concessione implicita possono ancora essere riscattati da un client riservato anche se il client pubblico ha un URI di reindirizzamento con caratteri jolly registrato.
Passaggi successivi
Altre informazioni sul protocollo OAuth 2.0 e su un altro modo per eseguire l'autenticazione da servizio a servizio che usa le credenziali del client: