Accès à l'API Azure AD Graph sans utiliser l'ID client et la clé secrète

Question

J'ai un service dorsal qui doit lire et écrire dans Azure AD. J'ai été capable de lire et d'écrire en utilisant graph api en authentifiant à l'aide des informations sur le locataire, l'ID client et la clé secrète (ces valeurs proviennent de Authentication Scenarios for Azure AD | Basics of Registering an Application in Azure AD). L'utilisation des informations sur le locataire, l'ID du client et la clé secrète pour l'authentification signifie que les utilisateurs finaux doivent enregistrer leurs locataires en spécifiant ces valeurs manuellement et j'essaie d'éviter cette étape manuelle d'enregistrement où les utilisateurs doivent spécifier ces valeurs.

J'ai également examiné le consentement administrateur/utilisateur de l'application multi-locataire et son échantillon associé Integrating applications with azure active directory. Cependant, le problème avec le consentement de l'administrateur est qu'il permet à tous les utilisateurs du répertoire d'avoir accès au répertoire. Y a-t-il une autre façon de fournir un lien d'enregistrement, laissez l'utilisateur admin global s'authentifier et donner son accord pour l'autorisation à quel point un type de jeton d'accès ou d'actualisation peut être conservé pour être utilisé par le back-office. service final?

Answer 1

J'ai le problème inverse (voir How to use Azure AD Graph API access for service principals?), mais je peux répondre à votre question. Les applications démon peuvent s'exécuter en tant que locataire unique ou multi-locataire et utiliser l'authentification utilisateur/mot de passe. Elles peuvent donc être limitées aux droits/rôles de cet utilisateur. J'ai testé cela en utilisant à la fois ID client/secret et utilisateur/mot de passe en utilisant la même application pour les deux - il suffit d'ajouter les autorisations nécessaires à l'application pour le cas utilisateur/mot de passe (cela ne semble pas s'appliquer aux SP).

Dans mon cas, je me sers adal4j, mais je suis sûr que vous pouvez l'adapter au besoin, .: par exemple

final ExecutorService service = Executors.newFixedThreadPool(1); 
final AuthenticationContext context = new AuthenticationContext(authority, true, service); 
final Future<AuthenticationResult> future = context.acquireToken("https://graph.windows.net", clientID, userName, decryptedPassword, null); 
final AuthenticationResult result = future.get(); 

...