Forgatókönyv: a webes API-kat meghívó alkalmazásScenario: Daemon application that calls web APIs

A webes API-kat meghívó Daemon-alkalmazások létrehozásához szükséges tudnivalók.Learn all you need to build a daemon application that calls web APIs.

ÁttekintésOverview

Az alkalmazás képes jogkivonatot beszerezni egy webes API saját nevében történő meghívására (nem a felhasználó nevében).Your application can acquire a token to call a web API on behalf of itself (not on behalf of a user). Ez a forgatókönyv a Daemon-alkalmazások esetében hasznos.This scenario is useful for daemon applications. A standard OAuth 2,0 ügyfél- hitelesítő adatok engedélyezését használja.It uses the standard OAuth 2.0 client credentials grant.

Démonalkalmazások

Íme néhány példa a Daemon-alkalmazások használati eseteire:Here are some examples of use cases for daemon apps:

  • A felhasználók üzembe helyezéséhez vagy felügyeletéhez, illetve a Batch-folyamatok címtárban való végrehajtásához használt webalkalmazásokWeb applications that are used to provision or administer users or do batch processes in a directory
  • Asztali alkalmazások (például Windows-szolgáltatások Windows-vagy Daemon-folyamatokhoz Linux rendszeren), amely batch-feladatokat hajt végre, vagy a háttérben futó operációsrendszer-szolgáltatás.Desktop applications (like Windows services on Windows or daemon processes on Linux) that perform batch jobs, or an operating system service that runs in the background
  • Webes API-k, amelyeknek a címtárakat kell kezelniük, nem meghatározott felhasználóknakWeb APIs that need to manipulate directories, not specific users

Van egy másik gyakori eset, amikor a nem Daemon-alkalmazások az ügyfél hitelesítő adatait használják: még akkor is, ha a felhasználók nevében cselekszenek, a webes API-t vagy az erőforrást a saját identitásuk alapján, technikai okokból kell elérniük.There's another common case where non-daemon applications use client credentials: even when they act on behalf of users, they need to access a web API or a resource under their own identity for technical reasons. Ilyen például a Azure Key Vault titkos kulcsaihoz való hozzáférés, vagy a gyorsítótár Azure SQL Database.An example is access to secrets in Azure Key Vault or Azure SQL Database for a cache.

Olyan alkalmazások, amelyek jogkivonatot szerzik be a saját identitásuk számára:Applications that acquire a token for their own identities:

  • Bizalmas ügyfélalkalmazások.Are confidential client applications. Ezek az alkalmazások, mivel a felhasználóktól függetlenül férnek hozzá az erőforrásokhoz, bizonyítaniuk kell identitásukat.These apps, given that they access resources independently of users, need to prove their identity. Ők is eléggé bizalmas alkalmazások.They're also rather sensitive apps. A Azure Active Directory (Azure AD) bérlői rendszergazdáinak jóvá kell hagyniuk.They need to be approved by the Azure Active Directory (Azure AD) tenant admins.
  • Titkos (alkalmazás jelszava vagy tanúsítvány) van regisztrálva az Azure AD-ben.Have registered a secret (application password or certificate) with Azure AD. Ezt a titkot a rendszer átadja az Azure AD-nek a jogkivonat beszerzésére irányuló hívásakor.This secret is passed in during the call to Azure AD to get a token.

SajátosságaiSpecifics

Fontos

  • A felhasználók nem tudnak kommunikálni egy démon alkalmazással.Users can't interact with a daemon application. Egy démon-alkalmazáshoz saját identitás szükséges.A daemon application requires its own identity. Az ilyen típusú alkalmazás hozzáférési jogkivonatot kér az alkalmazás identitásával, és megjeleníti az alkalmazás AZONOSÍTÓját, hitelesítő adatait (jelszavát vagy tanúsítványát), valamint az alkalmazás AZONOSÍTÓjának URI-JÁT az Azure AD-hez.This type of application requests an access token by using its application identity and presenting its application ID, credential (password or certificate), and application ID URI to Azure AD. A sikeres hitelesítés után a démon egy hozzáférési jogkivonatot (és egy frissítési jogkivonatot) kap a Microsoft Identity platform végpontból.After successful authentication, the daemon receives an access token (and a refresh token) from the Microsoft identity platform endpoint. Ezt a tokent a rendszer a webes API meghívására használja (és szükség szerint frissíti).This token is then used to call the web API (and is refreshed as needed).
  • Mivel a felhasználók nem tudnak kommunikálni a Daemon-alkalmazásokkal, a növekményes beleegyező engedély nem lehetséges.Because users can't interact with daemon applications, incremental consent isn't possible. Az összes szükséges API-engedélyt be kell állítani az alkalmazás regisztrálásakor.All the required API permissions need to be configured at application registration. Az alkalmazás kódja csak statikusan meghatározott engedélyeket kér.The code of the application just requests statically defined permissions. Ez azt is jelenti, hogy a Daemon-alkalmazások nem támogatják a növekményes hozzájárulásukat.This also means that daemon applications won't support incremental consent.

A fejlesztők számára a forgatókönyv teljes körű tapasztalata a következő szempontokat öleli fel:For developers, the end-to-end experience for this scenario has the following aspects:

  • A Daemon-alkalmazások csak az Azure AD-bérlők számára működhetnek.Daemon applications can work only in Azure AD tenants. Nem érdemes olyan Daemon-alkalmazást létrehozni, amely megkísérli a személyes Microsoft-fiókok kezelését.It wouldn't make sense to build a daemon application that attempts to manipulate Microsoft personal accounts. Ha Ön üzletági (LOB) alkalmazás fejlesztője, a démoni alkalmazást a bérlőben hozza létre.If you're a line-of-business (LOB) app developer, you'll create your daemon app in your tenant. Ha Ön ISV-t használ, érdemes lehet több-bérlős démon alkalmazást létrehoznia.If you're an ISV, you might want to create a multitenant daemon application. Minden bérlői rendszergazdának meg kell adnia a beleegyező jogosultságokat.Each tenant admin will need to provide consent.
  • Az alkalmazás regisztrálásasorán a válasz URI-ja nem szükséges.During application registration, the reply URI isn't needed. Meg kell osztania a titkokat, a tanúsítványokat vagy az aláírt állításokat az Azure AD-vel.You need to share secrets or certificates or signed assertions with Azure AD. Emellett meg kell adnia az alkalmazás engedélyeit, és rendszergazdai jóváhagyást kell adnia az alkalmazások használatához.You also need to request application permissions and grant admin consent to use those app permissions.
  • Az alkalmazás konfigurációjának az Azure ad-ben megosztott ügyfél-hitelesítő adatokat kell megadnia az alkalmazás regisztrációja során.The application configuration needs to provide client credentials as shared with Azure AD during the application registration.
  • Az ügyfél hitelesítő adataival rendelkező token beszerzéséhez használt hatókörnek statikus hatókörre van szüksége.The scope used to acquire a token with the client credentials flow needs to be a static scope.

Ha még nem ismeri a OAuth 2,0 és az OpenID Connect szolgáltatást, vagy akár csak most ismerkedik a Microsoft Identity platformon, az alábbi cikkeknek magasnak kell lenniük az olvasási listán.If you're new to identity and access management (IAM) with OAuth 2.0 and OpenID Connect, or even just new to IAM on the Microsoft identity platform, the following set of articles should be high on your reading list.

Bár az első gyors útmutató vagy oktatóanyag elvégzése előtt nem szükséges az olvasás, a platform szerves részét képező témaköröket fedi le, és a velük való ismeretek segítenek az Ön útvonalán az összetettebb forgatókönyvek kialakítása során.Although not required reading before completing your first quickstart or tutorial, they cover topics integral to the platform, and familiarity with them will help you on your path as you build more complex scenarios.

Következő lépésekNext steps