Stai creando un'API Web multi-tenant protetta da Azure AD. L'API deve autorizzare gli utenti in base ai ruoli (per l'accesso delegato dall'utente) e consentire anche ai servizi in background di chiamarla con autorizzazioni solo app utilizzando i ruoli. I token devono contenere attestazioni di ruolo che la tua API può valutare. Cosa dovresti implementare?

Le prime due opzioni sono corrette perché descrivono il metodo standard e raccomandato per implementare l'autorizzazione basata sui ruoli in un'API Web multi-tenant protetta da Azure AD, supportando sia gli utenti che le applicazioni. Definire i ruoli dell'app con allowedMemberTypes appropriati ("User" o "Application") consente ad Azure AD di includere le attestazioni di ruolo (roles) nei token, che l'API può poi convalidare. Questo approccio è flessibile e sicuro. La terza opzione è errata perché le autorizzazioni delegate (scopes) sono utilizzate per definire ciò che un'applicazione client può fare per conto di un utente, non per definire i ruoli dell'utente o dell'applicazione stessa. L'attestazione scp indica gli ambiti consentiti, non i ruoli. La quarta opzione è errata perché, sebbene i gruppi di Azure AD possano essere usati per l'autorizzazione, l'abilitazione di "emit groups as roles" nel manifesto dell'app è un approccio meno granulare e non è il metodo primario per definire ruoli specifici dell'applicazione che possono essere assegnati sia a utenti che a service principal in modo distinto e controllato. Inoltre, non gestisce nativamente i ruoli per le applicazioni daemon come le app roles.