Quelle est la différence exacte entre une application native et une application Web dans Azure Active Directory
Lorsque nous enregistrons une application dans Azure Active Directory pour utiliser l'API graphique, je constate qu'il existe deux types d'application Web d'application et d'application native.
Lors de la création d'une application Web, deux valeurs sont requises: 1. URL de connexion et 2. URL de l'ID d'application. Quelle est l'utilité de ces valeurs? Avons-nous besoin d'une URL réelle ou simplement https: // localhost: randomePort assez?
D'un autre côté, lors de la création d'une application native, je ne peux voir qu'une seule valeur requise "URL de redirection".
Je peux obtenir un jeton d'accès pour une application Web en utilisant REST call
POST https://login.microsoftonline.com/<tenant-id>/oauth2/token
grant_type client_credentials
client_id (the client ID of the calling service application in the AD)
client secret (the key configured in the calling service application in the AD)
resource https://graph.windows.net
Mais comment puis-je obtenir un jeton d'accès pour une application native en utilisant un tel appel REST?? Car il n'y a pas de secret client pour les applications natives
En ce qui concerne les autorisations, pour l'application native, je ne peux voir que l'option d'autorisations déléguées disponible tandis que pour l'application Web, je peux voir l'autorisation d'application ainsi que l'option d'autorisations déléguées.
Une dernière chose, au-dessus de REST authentifie l'application, comment puis-je authentifier l'utilisateur à l'aide de ses informations d'identification en utilisant REST?
Les applications natives sont des clients publics dans le langage OAuth2. Ces applications sont censées s'exécuter sur un appareil et ne sont pas fiables pour maintenir un secret - par conséquent, leur entrée dans le répertoire n'a pas la propriété correspondante. Sans secret, il n'y a aucun moyen d'affirmer l'identité de l'application - par conséquent, ces applications ne peuvent pas obtenir d'autorisations au niveau de l'application et l'UX du portail le reflète. Inversement, les applications Web sont, encore une fois dans le langage OAuth2, des clients confidentiels. Ils peuvent obtenir des jetons délégués pour leurs utilisateurs, mais ils peuvent également utiliser les informations d'identification du client pour obtenir eux-mêmes des jetons. Les applications natives peuvent obtenir des jetons pour l'utilisateur via l'octroi d'autorisation OAuth2. Vous pouvez trouver un aperçu complet de toutes les topologies prises en charge sur https://Azure.Microsoft.com/en-us/documentation/articles/active-directory-authentication-scenarios/ . Chaque description de scénario pointe vers des conseils plus orientés vers la mise en œuvre.