Contoso espone diversi servizi on-premise tramite App per la logica di Azure con trigger HTTP. Un'organizzazione partner (Fabrikam) utilizza un provider di identità OAuth 2.0 di terze parti (nessun tenant di Azure AD) e i suoi sviluppatori necessitano di accesso programmatico a un sottoinsieme delle app per la logica di Contoso. La soluzione deve: (1) consentire agli sviluppatori di Fabrikam di utilizzare il loro provider OAuth 2.0 esistente, (2) applicare limiti di frequenza più severi per le richieste dei partner rispetto agli utenti di Contoso, (3) non richiedere modifiche alle app per la logica esistenti e (4) non utilizzare account guest di Azure AD. Quale servizio dovresti includere nella progettazione?

La Gestione API di Azure è la soluzione corretta perché soddisfa tutti i requisiti. Permette l'integrazione con provider di identità OAuth 2.0 di terze parti per l'autenticazione dei partner (requisito 1). Consente di definire criteri di limitazione della frequenza (rate limiting) specifici per i partner, più stringenti rispetto ad altri utenti (requisito 2). Agisce come un gateway davanti alle App per la logica, senza richiedere modifiche a queste ultime (requisito 3). Infine, non si basa su account guest di Azure AD, rispettando il requisito 4. Azure Front Door è un CDN e bilanciatore di carico globale che offre funzionalità di sicurezza e routing, ma non gestisce l'autenticazione OAuth 2.0 di terze parti in modo nativo per le API. Il Proxy applicazione di Azure AD è progettato per esporre applicazioni on-premise tramite Azure AD, ma richiede l'uso di Azure AD per l'autenticazione, il che non soddisfa il requisito del provider OAuth 2.0 di terze parti e l'assenza di account guest. Azure AD B2B è un servizio di collaborazione che si basa sull'uso di account guest di Azure AD, violando il requisito 4.