Sdílet prostřednictvím

Aplikace service-to-service

  • Článek

Upozornění

Tento obsah je určený pro starší koncový bod Azure AD verze 1.0. U nových projektů použijte Microsoft identity platform.

Aplikace služba-služba může být démon nebo serverová aplikace, která potřebuje získat prostředky z webového rozhraní API. Pro tuto část platí dva dílčí scénáře:

  • Proces démon, který potřebuje volat webové rozhraní API založené na typu udělení přihlašovacích údajů klienta OAuth 2.0

    V tomto scénáři je důležité pochopit několik věcí. Zaprvé, interakce uživatele není možná s aplikací démona, která vyžaduje, aby aplikace měla svou vlastní identitu. Příkladem aplikace démona je dávková úloha nebo služba operačního systému spuštěná na pozadí. Tento typ aplikace vyžaduje přístupový token pomocí své identity aplikace a předložením ID aplikace, přihlašovacích údajů (hesla nebo certifikátu) a identifikátoru URI ID aplikace pro Azure AD. Po úspěšném ověření proces démon obdrží přístupový token z Azure AD, který se pak použije k volání webového rozhraní API.

  • Serverová aplikace (například webové rozhraní API), která potřebuje volat webové rozhraní API založené na specifikaci konceptu OAuth 2.0 On-Behalf-Of

    V tomto scénáři si představte, že uživatel se ověřil v nativní aplikaci a tato nativní aplikace potřebuje volat webové rozhraní API. Azure AD vydá přístupový token JWT pro volání webového rozhraní API. Pokud webové rozhraní API potřebuje volat jiné podřízené webové rozhraní API, může použít tok on-behalf-of k delegování identity uživatele a ověření do webového rozhraní API druhé vrstvy.

Diagram

Diagram rozhraní DAEMON nebo Server Application to Web API

Tok protokolu

Identita aplikace s udělením přihlašovacích údajů klienta OAuth 2.0

  1. Serverová aplikace se nejprve musí ověřit pomocí Azure AD sama, bez jakékoli lidské interakce, jako je interaktivní přihlašovací dialog. Vytvoří požadavek na koncový bod tokenu Azure AD a poskytne přihlašovací údaje, ID aplikace a identifikátor URI ID aplikace.
  2. Azure AD ověří aplikaci a vrátí přístupový token JWT, který se používá k volání webového rozhraní API.
  3. Přes HTTPS webová aplikace použije vrácený přístupový token JWT k přidání řetězce JWT s označením "Bearer" do autorizační hlavičky požadavku do webového rozhraní API. Webové rozhraní API pak ověří token JWT, a pokud je ověření úspěšné, vrátí požadovaný prostředek.

Delegovaná identita uživatele se specifikací OAuth 2.0 On-Behalf-Of Draft

Níže popsaný tok předpokládá, že uživatel byl ověřen v jiné aplikaci (například v nativní aplikaci) a jeho identita uživatele byla použita k získání přístupového tokenu k webovému rozhraní API první vrstvy.

  1. Nativní aplikace odešle přístupový token do webového rozhraní API první vrstvy.
  2. Webové rozhraní API první vrstvy odešle požadavek do koncového bodu tokenu Azure AD a poskytne ID a přihlašovací údaje aplikace a přístupový token uživatele. Kromě toho se požadavek odešle s parametrem on_behalf_of, který indikuje, že webové rozhraní API požaduje nové tokeny pro volání podřízeného webového rozhraní API jménem původního uživatele.
  3. Azure AD ověří, že webové rozhraní API první vrstvy má oprávnění pro přístup k webovému rozhraní API druhé vrstvy, a ověří požadavek a vrátí přístupový token JWT a obnovovací token JWT webovému rozhraní API první vrstvy.
  4. Webové rozhraní API první vrstvy přes HTTPS pak volá webové rozhraní API druhé vrstvy tím, že v požadavku připojí řetězec tokenu do autorizační hlavičky. Webové rozhraní API první vrstvy může pokračovat ve volání webového rozhraní API druhé vrstvy, pokud jsou přístupové a obnovovací tokeny platné.

Ukázky kódů

Projděte si ukázky kódu pro scénáře rozhraní API démona nebo serverové aplikace na web: Aplikace serveru nebo démona na webové rozhraní API.

Registrace aplikace

  • Jeden tenant – V případě identity aplikace i delegované identity uživatele musí být proces démon nebo serverová aplikace zaregistrované ve stejném adresáři v Azure AD. Webové rozhraní API je možné nakonfigurovat tak, aby zpřístupnilo sadu oprávnění, která se používají k omezení přístupu démona nebo serveru k jeho prostředkům. Pokud se používá delegovaný typ identity uživatele, musí serverová aplikace vybrat požadovaná oprávnění. Na stránce Oprávnění rozhraní API pro registraci aplikace po výběru možnosti Přidat oprávnění a zvolení řady rozhraní API zvolte Delegovaná oprávnění a pak vyberte svá oprávnění. Tento krok se nevyžaduje, pokud se používá typ identity aplikace.
  • Více tenantů – Nejprve je proces démon nebo serverová aplikace nakonfigurovaná tak, aby označovala oprávnění, která vyžaduje, aby byla funkční. Tento seznam požadovaných oprávnění se zobrazí v dialogovém okně, když uživatel nebo správce v cílovém adresáři udělí souhlas aplikaci a zpřístupní ji jeho organizaci. Některé aplikace vyžadují jenom oprávnění na úrovni uživatele, se kterými může souhlasit každý uživatel v organizaci. Jiné aplikace vyžadují oprávnění na úrovni správce, se kterými uživatel v organizaci nemůže souhlasit. Pouze správce adresáře může udělit souhlas aplikacím, které vyžadují tuto úroveň oprávnění. Když uživatel nebo správce souhlasí, obě webová rozhraní API se zaregistrují ve svém adresáři.

Vypršení platnosti tokenu

Když první aplikace použije svůj autorizační kód k získání přístupového tokenu JWT, obdrží také obnovovací token JWT. Po vypršení platnosti přístupového tokenu je možné obnovovací token použít k opětovnému ověření uživatele bez výzvy k zadání přihlašovacích údajů. Tento obnovovací token se pak použije k ověření uživatele, což vede k vytvoření nového přístupového tokenu a obnovovacího tokenu.

Další kroky