tok Microsoft identity platform a OAuth 2.0 On-Behalf-Of

Tok on-behalf-of (OBO) popisuje scénář webového rozhraní API, který k volání jiného webového rozhraní API používá jinou než vlastní identitu. V OAuth se označuje jako delegování a záměrem je předat identitu a oprávnění uživatele prostřednictvím řetězu žádostí.

Aby služba střední vrstvy odcestovala ověřené požadavky na podřízenou službu, musí zabezpečit přístupový token z Microsoft identity platform. Používá pouze delegovaný obor, nikoli aplikační role. Role zůstávají připojené k objektu zabezpečení (uživateli) a nikdy k aplikaci provozující jménem uživatele. Dochází k tomu, aby uživatel nezíslil oprávnění k prostředkům, ke kterým by neměl mít přístup.

Tento článek popisuje, jak vaši aplikaci programovat přímo s použitím protokolu. Pokud je to možné, doporučujeme místo toho k získání tokenů a volání zabezpečených webových rozhraní API použít podporované knihovny Microsoft Authentication Libraries (MSAL). Příklady najdete také v ukázkových aplikacích, které používají KNIHOVNu MSAL .

Tip

Zkuste spustit tento požadavek v nástroji Postman.
Zkuste spustit tento a další požadavky v nástroji Postman – nezapomeňte nahradit tokeny a ID.

Omezení klienta

Pokud instanční objekt požádal o token pouze pro aplikaci a odeslal ho do rozhraní API, vymění si toto rozhraní API token, který nepředstavuje původní instanční objekt. Je to proto, že tok OBO funguje pouze pro objekty zabezpečení uživatele. Místo toho musí k získání tokenu jen pro aplikaci použít tok přihlašovacích údajů klienta . V případě jednostránkových aplikací (SPA) by měly předat přístupový token důvěrnému klientovi střední vrstvy, který místo toho provede toky OBO.

Pokud klient používá implicitní tok k získání id_token a v adrese URL odpovědi má také zástupné é adresou, nelze pro tok OBO použít id_token. Zástupný znak je adresa URL, která končí znakem * . Pokud https://myapp.com/* například adresa URL odpovědi byla, id_token nelze použít, protože není dostatečně konkrétní k identifikaci klienta. Tím by se zabránilo vydání tokenu. Přístupové tokeny získané prostřednictvím toku implicitního udělení oprávnění však může důvěrný klient uplatnit, i když má iniciující klient zaregistrovanou adresu URL odpovědi se zástupným znakem. Je to proto, že důvěrný klient může identifikovat klienta, který získal přístupový token. Důvěrný klient pak může přístupový token použít k získání nového přístupového tokenu pro podřízené rozhraní API.

Aplikace s vlastními podpisovými klíči navíc není možné použít jako rozhraní API střední vrstvy v toku OBO. To zahrnuje podnikové aplikace nakonfigurované pro jednotné přihlašování. Pokud rozhraní API střední vrstvy používá vlastní podpisový klíč, podřízené rozhraní API nebude moct ověřit podpis přístupového tokenu, který je mu předán. Výsledkem bude chyba, protože tokeny podepsané klíčem řízeným klientem není možné bezpečně přijmout.

Diagram protokolu

Předpokládejme, že uživatel byl ověřen v aplikaci pomocí toku udělení autorizačního kódu OAuth 2.0 nebo jiného toku přihlášení. V tomto okamžiku má aplikace přístupový token pro rozhraní API A (token A) s deklaracemi identity uživatele a souhlasem s přístupem k webovému rozhraní API střední vrstvy (API A). Rozhraní API A teď musí provést ověřený požadavek na podřízené webové rozhraní API (API B).

Následující kroky tvoří tok OBO a jsou vysvětleny pomocí následujícího diagramu.

Zobrazuje tok OAuth 2.0 On-Behalf-Of.

  1. Klientská aplikace vytvoří požadavek na rozhraní API A s tokenem A (s deklarací aud identity rozhraní API A).
  2. Rozhraní API A se ověřuje v koncovém bodu vystavování tokenu Microsoft identity platform a požádá o token pro přístup k rozhraní API B.
  3. Koncový bod vystavování tokenu Microsoft identity platform ověří přihlašovací údaje rozhraní API A společně s tokenem A a vydá do rozhraní API A přístupový token pro rozhraní API B (token B).
  4. Token B nastavuje rozhraní API A v autorizační hlavičce požadavku na rozhraní API B.
  5. Rozhraní API B vrací data ze zabezpečeného prostředku do rozhraní API A a pak do klienta.

V tomto scénáři služba střední vrstvy nemá žádnou interakci uživatele, aby získala souhlas uživatele s přístupem k rozhraní API pro příjem dat. Proto se možnost udělení přístupu k rozhraní API pro příjem dat zobrazí předem jako součást kroku souhlasu během ověřování. Informace o tom, jak tento postup implementovat ve vaší aplikaci, najdete v tématu Získání souhlasu pro aplikaci střední vrstvy.

Žádost o přístupový token střední vrstvy

Pokud chcete požádat o přístupový token, nastavte na koncový bod tokenu tokenu Microsoft identity platform konkrétního tenanta příkaz HTTP POST s následujícími parametry.

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

Upozornění

NEPOSÍLEJTE přístupové tokeny vydané pro střední vrstvu žádné jiné straně. Přístupové tokeny vydané pro střední vrstvu jsou určeny pouze pro tuto střední vrstvu.

Mezi bezpečnostní rizika přenosu přístupových tokenů z prostředku střední vrstvy do klienta (místo toho, aby klient získál samotné přístupové tokeny), patří:

  • Zvýšené riziko zachycování tokenů přes ohrožené kanály SSL/TLS
  • Nemožnost splnit vazbu tokenů a scénáře podmíněného přístupu, které vyžadují zvýšení deklarací identity (například vícefaktorové ověřování, frekvence přihlašování).
  • Nekompatibilitu se zásadami zařízení nakonfigurovanými správcem (například MDM, zásady na základě umístění).

Existují dva případy v závislosti na tom, jestli se klientská aplikace rozhodne zabezpečit sdíleným tajným kódem nebo certifikátem.

První případ: Žádost o přístupový token se sdíleným tajným kódem

Při použití sdíleného tajného klíče obsahuje žádost o přístupový token service-to-service následující parametry:

Parametr Typ Popis
grant_type Povinné Typ požadavku na token. V případě požadavku, který používá JWT, musí být urn:ietf:params:oauth:grant-type:jwt-bearerhodnota .
client_id Vyžadováno ID aplikace (klienta), které Azure Portal – Registrace aplikací stránka přiřadila vaší aplikaci.
client_secret Vyžadováno Tajný klíč klienta, který jste vygenerovali pro aplikaci na stránce Azure Portal – Registrace aplikací. Podporuje se také základní způsob ověřování, který místo zadávání přihlašovacích údajů v autorizační hlavičce podle RFC 6749 .
assertion Vyžadováno Přístupový token odeslaný do rozhraní API střední vrstvy. Tento token musí mít deklaraci identity cílové skupiny (aud) aplikace, která tento požadavek OBO vytvořila (aplikace označená polem client-id ). Aplikace nemůžou uplatnit token pro jinou aplikaci (pokud například klient odešle rozhraní API token určený pro Microsoft Graph, nemůže ho rozhraní API uplatnit pomocí OBO. Místo toho by měl token odmítnout).
scope Vyžadováno Seznam oborů pro požadavek na token oddělený mezerami. Další informace najdete v tématu obory.
requested_token_use Vyžadováno Určuje, jak se má požadavek zpracovat. V toku OBO musí být hodnota nastavená na on_behalf_of.

Příklad

Následující protokol HTTP POST si vyžádá přístupový token a obnovovací token s oborem user.readhttps://graph.microsoft.com pro webové rozhraní API. Žádost je podepsána tajným kódem klienta a je vytvořená důvěrným klientem.

//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

Druhý případ: Žádost o přístupový token s certifikátem

Žádost o přístupový token service-to-service s certifikátem obsahuje kromě parametrů z předchozího příkladu i následující parametry:

Parametr Typ Popis
grant_type Povinné Typ požadavku na token. V případě požadavku, který používá JWT, musí být urn:ietf:params:oauth:grant-type:jwt-bearerhodnota .
client_id Vyžadováno ID aplikace (klienta), které Azure Portal – Registrace aplikací stránka přiřadila vaší aplikaci.
client_assertion_type Vyžadováno Hodnota musí být urn:ietf:params:oauth:client-assertion-type:jwt-bearer.
client_assertion Vyžadováno Kontrolní výraz (webový token JSON), který potřebujete vytvořit a podepsat certifikátem, který jste zaregistrovali jako přihlašovací údaje pro vaši aplikaci. Informace o tom, jak zaregistrovat certifikát a formát kontrolního výrazu, najdete v tématu věnovaném přihlašovacím údajům certifikátu.
assertion Vyžadováno Přístupový token odeslaný do rozhraní API střední vrstvy. Tento token musí mít deklaraci identity cílové skupiny (aud) aplikace, která tento požadavek OBO vytvořila (aplikace označená polem client-id ). Aplikace nemůžou uplatnit token pro jinou aplikaci (například pokud klient odešle rozhraní API token určený pro MS Graph, nemůže ho rozhraní API uplatnit pomocí OBO. Místo toho by měl token odmítnout).
requested_token_use Vyžadováno Určuje, jak se má žádost zpracovat. V toku OBO musí být hodnota nastavená na on_behalf_of.
scope Vyžadováno Seznam oborů oddělených mezerami pro žádost o token. Další informace najdete v tématu Obory.

Všimněte si, že parametry jsou téměř stejné jako v případě požadavku sdíleným tajným kódem s tím rozdílemclient_secret, že parametr je nahrazen dvěma parametry: client_assertion_type a .client_assertion Parametr client_assertion_type je nastavený na urn:ietf:params:oauth:client-assertion-type:jwt-bearer a client_assertion parametr je nastavený na token JWT, který je podepsaný privátním klíčem certifikátu.

Příklad

Následující protokol HTTP POST vyžaduje přístupový token s oborem user.readhttps://graph.microsoft.com pro webové rozhraní API s certifikátem. Požadavek je podepsaný tajným kódem klienta a vytvoří ho důvěrný klient.

// 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

Odpověď přístupového tokenu střední vrstvy

Úspěšná odpověď je odpověď JSON OAuth 2.0 s následujícími parametry.

Parametr Popis
token_type Označuje hodnotu typu tokenu. Jediný typ, který Microsoft identity platform podporuje, je Bearer. Další informace o nosných tokenech najdete v tématu OAuth 2.0 Authorization Framework: Použití nosných tokenů (RFC 6750).
scope Rozsah přístupu udělený v tokenu.
expires_in Doba platnosti přístupového tokenu (v sekundách).
access_token Požadovaný přístupový token. Volající služba může tento token použít k ověření v přijímající službě.
refresh_token Obnovovací token požadovaného přístupového tokenu. Volající služba může tento token použít k vyžádání dalšího přístupového tokenu po vypršení platnosti aktuálního přístupového tokenu. Obnovovací token se poskytne jenom v případě, že offline_access byl obor požadován.

Příklad úspěšné odpovědi

Následující příklad ukazuje úspěšnou odpověď na požadavek na přístupový token pro https://graph.microsoft.com webové rozhraní API. Odpověď obsahuje přístupový token a obnovovací token a je podepsána privátním klíčem certifikátu.

{
  "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}"
}

Tento přístupový token je token ve formátu v1.0 pro Microsoft Graph. Důvodem je to, že formát tokenu je založený na prostředku, ke který se přistupuje, a nesouvisí s koncovými body použitými k jeho vyžádání. Microsoft Graph je nastavený tak, aby přijímal tokeny v1.0, takže Microsoft identity platform vytváří přístupové tokeny verze 1.0, když klient požádá o tokeny pro Microsoft Graph. Jiné aplikace můžou znamenat, že chtějí tokeny ve formátu v2.0, tokeny ve formátu v1.0 nebo dokonce proprietární nebo šifrované formáty tokenů. Koncové body v1.0 i v2.0 můžou generovat oba formáty tokenu. Tímto způsobem může prostředek vždy získat správný formát tokenu bez ohledu na to, jak nebo kde byl token požadován klientem.

Upozornění

Nepokoušejte se ověřovat ani číst tokeny pro žádné rozhraní API, které nevlastníte, včetně tokenů v tomto příkladu, ve vašem kódu. Tokeny pro Microsoft služby můžou používat speciální formát, který se neověřuje jako JWT a může být také šifrovaný pro uživatele uživatelů (Microsoft účtu). Čtení tokenů je užitečný nástroj pro ladění a výuku, ale nepřebídejte na nich v kódu závislosti ani nepředpokládáte specifika tokenů, které nejsou pro rozhraní API, které ovládáte.

Příklad odpovědi na chybu

Při pokusu o získání přístupového tokenu pro podřízené rozhraní API vrátí koncový bod tokenu chybovou odpověď, pokud má podřízené rozhraní API nastavené zásady podmíněného přístupu (například vícefaktorové ověřování). Služba střední vrstvy by měla tuto chybu zobrazit v klientské aplikaci, aby klientská aplikace mohla poskytovat interakci s uživatelem, aby splňovala zásady podmíněného přístupu.

{
    "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\"]}}}"
}

Použití přístupového tokenu pro přístup k zabezpečenému prostředku

Služba střední vrstvy teď může pomocí výše získaného tokenu provádět ověřené požadavky na podřízené webové rozhraní API nastavením tokenu Authorization v hlavičce.

Příklad

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

Kontrolní výrazy SAML získané s tokem OBO OAuth2.0

Některé webové služby založené na OAuth potřebují přístup k jiným rozhraním API webových služeb, která přijímají kontrolní výrazy SAML v neinteraktivních tocích. Azure Active Directory může poskytnout kontrolní výraz SAML v reakci na tok On-Behalf-Of, který jako cílový prostředek používá webovou službu založenou na SAML.

Jedná se o nestandardní rozšíření toku OAuth 2.0 On-Behalf-Of, které aplikaci založené na OAuth2 umožňuje přístup ke koncovým bodům rozhraní API webové služby, které využívají tokeny SAML.

Tip

Když voláte webovou službu chráněnou SAML z front-endové webové aplikace, můžete jednoduše volat rozhraní API a zahájit normální tok interaktivního ověřování s existující relací uživatele. Tok OBO potřebujete použít pouze v případech, kdy volání mezi službami vyžaduje token SAML k poskytnutí kontextu uživatele.

Získání tokenu SAML pomocí požadavku OBO se sdíleným tajným kódem

Požadavek mezi službami pro kontrolní výraz SAML obsahuje následující parametry:

Parametr Typ Description
grant_type vyžadováno Typ požadavku na token. U požadavku, který používá JWT, musí být urn:ietf:params:oauth:grant-type:jwt-bearerhodnota .
Tvrzení vyžadováno Hodnota přístupového tokenu použitého v požadavku.
client_id vyžadováno ID aplikace přiřazené volající službě během registrace v Azure AD. Pokud chcete najít ID aplikace v Azure Portal, vyberte Active Directory, zvolte adresář a pak vyberte název aplikace.
client_secret vyžadováno Klíč zaregistrovaný pro volající službu v Azure AD. Tato hodnota by měla být zaznamenána v době registrace. Podporuje se také model základního ověřování, který místo zadávání přihlašovacích údajů v hlavičce autorizace odpovídá dokumentu RFC 6749 .
scope vyžadováno Seznam oborů oddělených mezerami pro žádost o token. Další informace najdete v tématu Obory. SamL sám o sobě nemá koncept oborů, ale používá se k identifikaci cílové aplikace SAML, pro kterou chcete získat token. Pro tento tok OBO musí být hodnotou oboru vždy ID entity SAML s připojeným kódem /.default . Pokud je https://testapp.contoso.comnapříklad ID entity aplikace SAML , požadovaný obor by měl být https://testapp.contoso.com/.default. V případě, že ID entity nezačíná schématem identifikátoru URI, jako https:je , Azure AD předponu ID entity s spn:. V takovém případě musíte požádat o rozsah spn:<EntityID>/.default, například spn:testapp/.default v případě, že je testappID entity . Hodnota oboru, kterou zde požadujete, určuje výsledný Audience prvek v tokenu SAML, který může být důležitý pro aplikaci SAML, která token přijímá.
requested_token_use vyžadováno Určuje, jak se má žádost zpracovat. V toku On-Behalf-Of musí být on_behalf_ofhodnota .
requested_token_type vyžadováno Určuje typ požadovaného tokenu. Hodnota může být urn:ietf:params:oauth:token-type:saml2 nebo urn:ietf:params:oauth:token-type:saml1 v závislosti na požadavcích používaného prostředku.

Odpověď obsahuje token SAML kódovaný v UTF8 a Base64url.

  • SubjectConfirmationData pro kontrolní výraz SAML z volání objektu OBO: Pokud cílová aplikace vyžaduje Recipient hodnotu v SubjectConfirmationData, musí být hodnota nakonfigurovaná jako první adresa URL odpovědi bez zástupných znaků v konfiguraci aplikace prostředků. Vzhledem k tomu, že výchozí adresa URL odpovědi se k určení Recipient hodnoty nepoužívá, budete možná muset změnit pořadí adres URL odpovědí v konfiguraci aplikace, abyste zajistili, že se použije první adresa URL odpovědi, která není zástupným znakem. Další informace najdete v tématu Adresy URL odpovědí.
  • Uzel SubjectConfirmationData: Uzel nemůže obsahovat InResponseTo atribut, protože není součástí odpovědi SAML. Aplikace přijímající token SAML musí být schopná přijmout kontrolní výraz SAML bez atributu InResponseTo .
  • Oprávnění rozhraní API: Abyste povolili přístup k aplikaci SAML, musíte do aplikace střední vrstvy přidat potřebná oprávnění rozhraní API , aby mohla požádat o token pro /.default obor aplikace SAML.
  • Souhlas: K získání tokenu SAML obsahujícího uživatelská data v toku OAuth musí být udělen souhlas. Informace najdete v části Získání souhlasu pro aplikaci střední vrstvy níže.

Odpověď s kontrolním výrazem SAML

Parametr Popis
token_type Označuje hodnotu typu tokenu. Jediný typ, který Azure AD podporuje, je Bearer. Další informace o nosných tokenech najdete v tématu OAuth 2.0 Authorization Framework: Použití nosných tokenů (RFC 6750).
scope Rozsah přístupu udělený v tokenu.
expires_in Doba platnosti přístupového tokenu (v sekundách).
expires_on Čas vypršení platnosti přístupového tokenu. Datum je vyjádřeno jako počet sekund od 1970-01-01T0:0:0Z UTC do času vypršení platnosti. Tato hodnota se používá k určení doby života tokenů uložených v mezipaměti.
prostředek Identifikátor URI ID aplikace přijímající služby (zabezpečený prostředek)
access_token Parametr, který vrací kontrolní výraz SAML.
refresh_token Obnovovací token. Volající služba může tento token použít k vyžádání dalšího přístupového tokenu po vypršení platnosti aktuálního kontrolního výrazu SAML.
  • token_type: Nosný
  • expires_in: 3296
  • ext_expires_in: 0
  • expires_on: 1529627844
  • Zdrojů: https://api.contoso.com
  • access_token: <Kontrolní výraz SAML>
  • issued_token_type: urn:ietf:params:oauth:token-type:saml2
  • refresh_token: <Obnovte token>

Cílem toku OBO je zajistit udělení správného souhlasu, aby klientská aplikace mohl volat aplikaci střední vrstvy a aby aplikace střední vrstvy získala oprávnění k volání back-endového prostředku. V závislosti na architektuře nebo využití vaší aplikace můžete zvážit následující skutečnosti, abyste zajistili, že tok OBO bude úspěšný.

Aplikace střední vrstvy přidá klienta do seznamu známých klientských aplikací (knownClientApplications) ve svém manifestu. Pokud klient aktivuje výzvu k vyjádření souhlasu, tok souhlasu bude pro sebe i pro aplikaci střední vrstvy. Na Microsoft identity platform se k tomu používá .default obor . Obor .default je speciální obor, který se používá k vyžádání souhlasu s přístupem ke všem oborům, ke kterým má aplikace oprávnění. To je užitečné, když aplikace potřebuje přístup k více prostředkům, ale uživatel by měl být vyzván k vyjádření souhlasu pouze jednou.

Při aktivaci obrazovky souhlasu pomocí známých klientských aplikací a .defaultse na obrazovce souhlasu zobrazí oprávnění klienta k rozhraní API střední vrstvy a také požadovaná oprávnění, která rozhraní API střední vrstvy vyžaduje. Uživatel poskytne souhlas pro obě aplikace a pak funguje tok OBO.

Služba prostředků (API) identifikovaná v požadavku by měla být rozhraní API, pro které klientská aplikace v důsledku přihlášení uživatele požaduje přístupový token. Například scope=openid https://middle-tier-api.example.com/.default (pokud chcete požádat o přístupový token pro rozhraní API střední vrstvy) nebo scope=openid offline_access .default (pokud prostředek není identifikovaný, ve výchozím nastavení se Microsoft Graph).

Bez ohledu na to, které rozhraní API je uvedené v žádosti o autorizaci, se výzva k vyjádření souhlasu zkombinuje se všemi požadovanými oprávněními nakonfigurovanými pro klientskou aplikaci. Kromě toho jsou zahrnuta také všechna požadovaná oprávnění nakonfigurovaná pro každé rozhraní API střední vrstvy uvedená v seznamu požadovaných oprávnění klienta, která identifikovala klienta jako známou klientskou aplikaci.

Předem autorizované aplikace

Prostředky můžou znamenat, že daná aplikace má vždy oprávnění přijímat určité obory. To je užitečné k zajištění bezproblémového připojení mezi front-endovým klientem a back-endovým prostředkem. Prostředek může ve svém manifestu deklarovat více předem autorizovaných aplikací (preAuthorizedApplications). Každá taková aplikace si může vyžádat tato oprávnění v toku OBO a získat je bez souhlasu uživatele.

Správce tenanta může zaručit, že aplikace mají oprávnění volat požadovaná rozhraní API tím, že udělí souhlas správce pro aplikaci střední vrstvy. Za tímto účelem může správce najít aplikaci střední vrstvy ve svém tenantovi, otevřít stránku požadovaná oprávnění a rozhodnout se, že aplikaci udělí oprávnění. Další informace o souhlasu správce najdete v dokumentaci k vyjádření souhlasu a oprávnění.

Použití jedné aplikace

V některých scénářích můžete mít pouze jedno párování klienta střední vrstvy a front-endu. V tomto scénáři může být jednodušší vytvořit z této jediné aplikace, což zcela vymění potřebu aplikace střední vrstvy. K ověřování mezi front-endem a webovým rozhraním API můžete použít soubory cookie, id_token nebo přístupový token požadovaný pro samotnou aplikaci. Potom vyžádejte od této jediné aplikace souhlas s back-endovým prostředkem.

Další kroky

Přečtěte si další informace o protokolu OAuth 2.0 a dalším způsobu ověřování mezi službami pomocí přihlašovacích údajů klienta.