Microsoft identity platform a protokol OAuth 2,0 za běhu

OBO (OAuth 2,0 on-of-jménem toku) slouží k použití případu, kdy aplikace vyvolá službu nebo webové rozhraní API, která zase potřebuje volat jiné služby nebo webové rozhraní API. Nápad je rozšířit identitu delegovaného uživatele a oprávnění prostřednictvím řetězce požadavků. aby služba střední vrstvy prováděla ověřené požadavky na službu pro příjem dat, potřebuje k zabezpečení přístupového tokenu z Microsoft identity platform jménem uživatele.

Tok OBO funguje pouze pro objekty zabezpečení uživatele v tomto okamžiku. Instanční objekt nemůže požádat o token pouze pro aplikace, odeslat ho do rozhraní API a tuto výměnu rozhraní API pro jiný token, který představuje původní instanční objekt. Tok OBO se navíc zaměřuje na jednání jménem jiné strany, označované jako Delegovaný scénář – to znamená, že používá pro účely odůvodnění oprávnění pouze delegované obory, nikoli aplikační role. Role zůstávají v toku připojené k objektu zabezpečení (uživatel), a ne aplikaci, která na nich zastupuje uživatel.

Tento článek popisuje, jak programovat přímo s protokolem ve vaší aplikaci. Pokud je to možné, doporučujeme místo toho použít podporované knihovny Microsoft Authentication Library (MSAL) k získání tokenů a volání zabezpečených webových rozhraní API. Podívejte se také na ukázkové aplikace, které používají MSAL.

Od května 2018 se v id_token OBO toku nedá použít nějaký odvozený implicitní tok. Jednostránkové aplikace (jednostránkové) by měly předat přístupovému klientovi střední vrstvy přístupový token, aby se místo toho prováděly OBO toky. Další informace o tom, kteří klienti můžou provádět volání OBO, najdete v tématu omezení.

Tip

Zkuste tento požadavek v postmanu spuštěný.
Zkuste tento požadavek a další informace odeslat v Postmanu – nezapomeňte nahradit tokeny a ID.

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 pro přístup k webovému rozhraní API střední vrstvy (API a). Rozhraní API nyní potřebuje ověřený požadavek webového rozhraní API pro příjem dat (API B).

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

Zobrazuje tok za běhu OAuth 2.0.

  1. Klientská aplikace vytvoří požadavek na rozhraní API A s tokenem A (s aud DEKLARACÍ API a).
  2. rozhraní api se ověřuje pro koncový bod vystavování tokenu Microsoft identity platform a požaduje token pro přístup k rozhraní API B.
  3. koncový bod vystavení tokenu Microsoft identity platform ověřuje přihlašovací údaje rozhraní api spolu s tokenem a a vydá přístupový token pro rozhraní api b (token B) k rozhraní api a.
  4. Token B je nastaven rozhraním API A v autorizační hlavičce požadavku na rozhraní API B.
  5. Data z zabezpečeného prostředku jsou vrácena rozhraním API B do rozhraní API A a následně klientovi.

V tomto scénáři nemá služba střední vrstvy žádnou interakci s uživatelem, aby získala souhlas uživatele s přístupem k rozhraní API pro příjem dat. Proto možnost udělení přístupu k rozhraní API pro příjem dat se při ověřování prezentuje jako součást kroku souhlasu. Informace o tom, jak tuto aplikaci nastavit, 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, vytvořte HTTP POST do koncového bodu tokenu Microsoft identity platform pro konkrétního klienta s následujícími parametry.

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

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

První případ: žádost přístupového tokenu se sdíleným tajným klíčem

Při použití sdíleného tajného klíče obsahuje požadavek na přístupový token služby na službu následující parametry:

Parametr Typ Popis
grant_type Povinné Typ žádosti o token Pro požadavek používající token JWT musí být hodnota urn:ietf:params:oauth:grant-type:jwt-bearer .
client_id Vyžadováno ID aplikace (klienta), které stránka Azure Portal-registrace aplikací přiřadila k vaší aplikaci.
client_secret Vyžadováno Tajný kód klienta, který jste vygenerovali pro vaši aplikaci na stránce Azure Portal-Registrace aplikací. Základní vzor ověřování místo toho, aby poskytoval přihlašovací údaje v autorizační hlavičce, je také podporován na základě RFC 6749 .
assertion Vyžadováno Přístupový token, který se odeslal do rozhraní API střední vrstvy. Tento token musí mít aud deklaraci identity cílové skupiny () aplikace, která tuto žádost OBO (aplikace označuje client-id pole). aplikace nemůžou uplatnit token pro jinou aplikaci (takže pokud klient pošle token rozhraní API, který je určený pro MS Graph, rozhraní api ho nemůže uplatnit pomocí OBO. Místo toho by se měl token zamítnout.
scope Vyžadováno Mezerou oddělený seznam oborů pro požadavek na token. 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 nastavena na on_behalf_of .

Příklad

Následující příspěvek HTTP požaduje přístupový token a aktualizuje token s user.read oborem pro https://graph.microsoft.com webové rozhraní API.

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

Požadavek na přístupový token služby na službu s certifikátem obsahuje následující parametry:

Parametr Typ Popis
grant_type Povinné Typ požadavku tokenu Pro požadavek používající token JWT musí být hodnota urn:ietf:params:oauth:grant-type:jwt-bearer .
client_id Vyžadováno ID aplikace (klienta), které stránka Azure Portal-registrace aplikací přiřadila k 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 k vytvoření a podepsání certifikátu, 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 přihlašovací údaje certifikátu.
assertion Vyžadováno Přístupový token, který se odeslal do rozhraní API střední vrstvy. Tento token musí mít aud deklaraci identity cílové skupiny () aplikace, která tuto žádost OBO (aplikace označuje client-id pole). aplikace nemůžou uplatnit token pro jinou aplikaci (takže pokud klient pošle token rozhraní API, který je určený pro MS Graph, rozhraní api ho nemůže uplatnit pomocí OBO. Místo toho by se měl token zamítnout.
requested_token_use Vyžadováno Určuje, jak se má požadavek zpracovat. V toku OBO musí být hodnota nastavena na on_behalf_of .
scope Vyžadováno Mezerou oddělený seznam oborů pro požadavek na token. Další informace najdete v tématu obory.

Všimněte si, že parametry jsou skoro stejné jako v případě požadavku pomocí sdíleného tajného kódu s tím rozdílem, že client_secret parametr je nahrazen dvěma parametry: client_assertion_type a a client_assertion .

Příklad

Následující příspěvek HTTP požaduje přístupový token s user.read oborem pro https://graph.microsoft.com webové rozhraní API s certifikátem.

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

Odezva přístupového tokenu střední vrstvy

Odpověď na úspěch je odpověď protokolu JSON OAuth 2,0 s následujícími parametry.

Parametr Popis
token_type Určuje hodnotu typu tokenu. jediný typ, který Microsoft identity platform podporuje, je Bearer . Další informace o nosných tokenech najdete v části autorizační rozhraní OAuth 2,0: použití nosných tokenů (RFC 6750).
scope Rozsah přístupu uděleného v tokenu.
expires_in Doba, po kterou je přístupový token platný (v sekundách).
access_token Požadovaný přístupový token Volající služba může tento token použít k ověření pro přijímající službu.
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í jiného přístupového tokenu po vypršení platnosti aktuálního přístupového tokenu. Aktualizační token je poskytován pouze v případě, že offline_access byl požadován obor.

Příklad odpovědi na úspěch

Následující příklad ukazuje odpověď na úspěch na žádost o přístupový token pro https://graph.microsoft.com webové rozhraní API.

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

Výše přístupový token je ve formátu Microsoft Graph v 1.0. Důvodem je to, že formát tokenu je založený na prostředku , ke kterému se přistupoval a který nesouvisí s koncovými body použitými k vyžádání. Microsoft Graph je instalační program, který přijme tokeny v 1.0, takže Microsoft identity platform tokeny v 1.0 vygeneruje v případě, že klient požaduje tokeny pro Microsoft Graph. Jiné aplikace mohou značit, že mají tokeny formátu v 2.0, tokeny formátu v 1.0 nebo dokonce speciální nebo šifrované formáty tokenů. Koncové body v 1.0 a v 2.0 můžou emitovat buď formát tokenu – tímto způsobem může prostředek vždycky získat správný formát tokenu bez ohledu na to, jak nebo kde byl token vyžádán klientem.

Upozornění

Nepokoušejte se ve svém kódu ověřovat ani číst tokeny pro žádné rozhraní API, které vlastníte, včetně tokenů v tomto příkladu. Tokeny pro služby Microsoft mohou používat speciální formát, který se neověřuje jako JWT a může být také šifrován pro uživatele příjemce (účet Microsoft). Čtení tokenů je užitečný nástroj pro ladění a učení, ale nezá závislostí na tomto tokenu v kódu ani předpokládejte konkrétní informace o tokenech, které nejsou pro rozhraní API, které řídíte.

Příklad chybové odpovědi

Koncový bod tokenu vrátí chybovou odpověď při pokusu o získání přístupového tokenu pro rozhraní API pro příjem dat, pokud má podřízené rozhraní API zásady podmíněného přístupu (například vícefaktorové ověřování) nastavené na tomto počítači. Služba střední vrstvy by tuto chybu měla obit klientské aplikaci, aby mohla klientská aplikace poskytnout interakci uživatele, aby splnila 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\"]}}}"
}

Přístup k zabezpečenému prostředku pomocí přístupového tokenu

Služba střední vrstvy teď může použít token získaný výše k provádění ověřených požadavků webového rozhraní API pro příjem dat, a to nastavením tokenu v Authorization záhlaví.

Příklad

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

Kontrolní výrazy SAML získané pomocí toku OBO OAuth 2.0

Některé webové služby založené na protokolu OAuth potřebují přístup k další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, který používá webovou službu založenou na saml jako cílový prostředek.

Toto je nestandardní rozšíření pro tok OAuth 2,0, který umožňuje aplikaci založené na OAuth2 přistupovat k koncovým bodům rozhraní API webové služby, které využívají tokeny SAML.

Tip

Když zavoláte webovou službu chráněnou SAML z front-endové webové aplikace, můžete jednoduše zavolat rozhraní API a zahájit normální tok interaktivního ověřování s existující relací uživatele. Tok OBO je potřeba použít jenom v případě, že volání služba-služba vyžaduje, aby token SAML poskytoval kontext uživatele.

Získání tokenu SAML pomocí žádosti OBO se sdíleným tajným klíčem

Požadavek služby na službu pro kontrolní výraz SAML obsahuje následující parametry:

Parametr Typ Description
grant_type vyžadováno Typ požadavku tokenu Pro požadavek, který používá JWT, musí být hodnota urn: IETF: params: OAuth: Grant-Type: JWT-nosič.
Neplatný vyžadováno Hodnota přístupového tokenu použitého v žádosti
client_id vyžadováno ID aplikace přiřazené volající službě během registrace ve službě Azure AD. Chcete-li najít ID aplikace v Azure Portal, vyberte možnost Active Directory, zvolte adresář a pak vyberte název aplikace.
client_secret vyžadováno Klíč zaregistrovaný pro volající službu ve službě Azure AD. Tato hodnota by se měla poznamenat v době registrace. Základní vzor ověřování místo toho, aby poskytoval přihlašovací údaje v autorizační hlavičce, je také podporován na základě RFC 6749 .
scope vyžadováno Mezerou oddělený seznam oborů pro požadavek na token. Další informace najdete v tématu obory. Například ' https://testapp.contoso.com/user_impersonation OpenID '
requested_token_use vyžadováno Určuje, jak se má požadavek zpracovat. V toku musí být hodnota on_behalf_of.
requested_token_type vyžadováno Určuje typ požadovaného tokenu. Hodnota může být urn: IETF: params: OAuth: token-Type: typu Saml2 nebo urn: IETF: parametr: OAuth: token-Type: saml1 v závislosti na požadavcích na prostředek, který je k dispozici.

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

  • SubjectConfirmationData pro vyhodnocení výrazu SAML ze volání OBO: Pokud cílová aplikace vyžaduje hodnotu příjemce v SubjectConfirmationData, musí být v konfiguraci aplikace prostředků adresa URL odpovědi bez zástupných znaků.

  • Uzel SubjectConfirmationData: uzel nemůže obsahovat atribut InResponseTo , protože není součástí odpovědi SAML. Aplikace, která přijímá token SAML, musí být schopna přijmout kontrolní výraz SAML bez atributu InResponseTo .

  • Souhlas: souhlas se musí udělit pro příjem tokenu SAML obsahujícího uživatelská data v toku OAuth. informace o oprávněních a získání souhlasu správce najdete v tématu oprávnění a souhlas v koncovém bodu Azure Active Directory v 1.0.

Odpověď s kontrolním výrazem SAML

Parametr Popis
token_type Určuje hodnotu typu tokenu. Jediným typem, který podporuje Azure AD, je nosič. Další informace o tokenech nosiče najdete v tématu autorizační rozhraní OAuth 2,0: použití nosných tokenů (RFC 6750).
scope Rozsah přístupu uděleného v tokenu.
expires_in Délka doby platnosti přístupového tokenu (v sekundách).
expires_on Čas vypršení platnosti přístupového tokenu. Datum se reprezentuje jako počet sekund od roku 1970-01-01T0:0: 0Z UTC až do doby 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ého prostředku)
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í jiného přístupového tokenu po vypršení platnosti aktuálního kontrolního výrazu SAML.
  • token_type: nosič
  • expires_in: 3296
  • ext_expires_in: 0
  • expires_on: 1529627844
  • partner https://api.contoso.com
  • access_token: <SAML assertion>
  • issued_token_type: urn: IETF: param: OAuth: typ tokenu: typu Saml2
  • refresh_token: <Refresh token>

V závislosti na architektuře nebo využití vaší aplikace můžete zvážit různé strategie pro zajištění úspěšnosti OBO toku. Ve všech případech je konečným cílem zajistit, aby klientská aplikace mohla zavolat aplikaci střední vrstvy a aplikace střední vrstvy má oprávnění k volání prostředku back-endu.

Poznámka

Dřív účet Microsoft systém (osobní účty) nepodporoval pole známá klientská aplikace, ani by nemohl zobrazit kombinovaný souhlas. přidaná a všechny aplikace v Microsoft identity platform můžou používat přístup ke známým klientským aplikacím pro získání souhlasu OBO volání.

Aplikace střední vrstvy přidá klienta do seznamu známých klientských aplikací ve svém manifestu a klient může aktivovat kombinovaný postup souhlasu pro sebe i pro aplikaci střední vrstvy. v Microsoft identity platform se to provádí pomocí /.default oboru. Při aktivaci obrazovky pro vyjádření souhlasu pomocí známých klientských aplikací a /.default na obrazovce pro vyjádření souhlasu se zobrazí oprávnění pro klienta pro rozhraní API střední vrstvy a také si vyžádají jakékoli oprávnění, které jsou vyžadovány rozhraním API střední vrstvy. Uživatel vyhověl oběma aplikacím a pak funguje tok OBO.

Předem autorizované aplikace

Prostředky mohou indikovat, že určitá aplikace má vždy oprávnění přijímat určité obory. To je užitečné hlavně k tomu, aby se připojení mezi front-end klientem a back-endem bezproblémověji prováděla. Prostředek může deklarovat více předem autorizovaných aplikací – každá taková aplikace si může tato oprávnění vyžádat v toku OBO a přijímat 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 pro aplikaci střední vrstvy poskytne souhlas správce. Správce tak může ve svém tenantovi najít aplikaci střední vrstvy, otevřít stránku požadovaných oprávnění a udělit jí oprávnění. Další informace o souhlasu správce najdete v dokumentaci k souhlasu a oprávněním.

Použití jedné aplikace

V některých scénářích můžete mít pouze jednu dvojici klienta střední vrstvy a front-endu. V tomto scénáři můžete snáze vytvořit jednu aplikaci, která zcela neguje potřebu aplikace střední vrstvy. K ověření 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 požádejte o souhlas z této jediné aplikace do back-endového prostředku.

Omezení klienta

Pokud klient používá implicitní tok k získání id_token a tento klient má v adrese URL odpovědi také zástupné znaky, id_token nelze použít pro tok OBO. Přístupové tokeny získané prostřednictvím implicitního toku udělení však může uplatnit důvěrný klient i v případě, že iniciující klient má zaregistrovanou adresu URL odpovědi se zástupnými znaky.

Další kroky

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