Короткий ответ : Принцип приложения и службы - это, безусловно, две разные вещи (связанные в 1: много модных, но определенно разных объектов).
Работа с API-интерфейсом Azure AD Graph
Поиск приложения. Как вы уже упоминали в вопросе.
https://graph.windows.net/<tenantName>/applications?api-version=1.6&$filter=displayName eq '<Apllication Name>'
Поиск руководителя службы
https://graph.windows.net/<tenantName>/servicePrincipals?api-version=1.6&$filter=displayName eq '<Apllication Name>'
Мелочи, которые нужно заметить в json:
objectId и objectType будут отличаться для объекта приложения и объекта субъекта службы, которые вы получаете от вышеупомянутых запросов. - Свойства типа
appId и displayName одинаковы, поскольку они связаны с одним и тем же логическим приложением.
Ваш вопрос о том, какова связь между AppID и ServicePrincipalID (и ClientID, ObjectID)
Во-первых, ссылка в вашем вопросе Объекты субъекта приложения и службы в Azure Active Directory - отличный ресурс для понимания концепций. Я не буду лучше, чем эта документация, объяснять концепции, поэтому, если нужно, прочитайте ее несколько раз. Я постараюсь выделить некоторую информацию, чтобы ответить на ваши конкретные вопросы, хотя.
Вы можете рассматривать объект приложения, который вы извлекли из API-интерфейса Azure AD Graph выше (или см. В разделе «Регистрация приложений» портала Azure> Azure Active Directory), как единственное и основное определение разрабатываемого вами программного приложения и регистрация в Azure AD в целях идентификации. ПРИМЕЧАНИЕ. В случае мультитенантных приложений этот объект приложения можно найти только в «домашнем» клиенте, где приложение было зарегистрировано в Azure AD.
Участник службы (то, что вы видите в разделе Корпоративные приложения портала Azure> Azure Active Directory), с другой стороны, создается в каждом клиенте Azure AD, который хочет использовать это приложение. Для «домашнего» арендатора принципал службы создается во время регистрации приложения, для всех остальных арендаторов принципал создается в момент согласия.
Таким образом, всегда будет только 1 объект приложения для представления приложения. Во время регистрации приложения будет создан как минимум 1 участник службы. Хотя, когда вы начнете использовать мультитенантное приложение от нескольких арендаторов, для каждого нового арендатора Azure AD будет создан 1 участник службы, где пользователь дает согласие на приложение. Следовательно, отношение между приложением и объектом субъекта службы становится равным 1: много
appId будет одинаковым для одного объекта приложения, представляющего это приложение, а также для всех участников службы, созданных для этого приложения. objectId будет уникальным значением для объекта приложения и каждого участника службы. Это однозначно определяет объект в Azure AD. Это свойство вы найдете во всех объектах Azure AD, таких как пользователь, группа или что-либо еще в Azure AD. clientId будет таким же, как appId. Это будет актуально в контексте, например, получения токена с использованием одного из потоков OAuth, которые поддерживает Azure AD (например, при написании кода с использованием библиотек ADAL или с помощью API REST для достижения конечных точек токена Azure AD). Это не прямое свойство, которое вы найдете с таким точным именем для объекта приложения или субъекта службы.
Кстати, две другие ссылки, которые вас смутили, - это скорее статья «Как писать статьи, пытающаяся выполнить работу», чем глубокое объяснение понятий, которые вы ищете. Я не думаю, что какая-либо документация прямо скажет, что приложение и принципал службы - это одно и то же (поскольку технически это не так). Хотя я могу понять, как иногда это может сбить с толку, когда приложение и субъект-служба используются взаимозаменяемо, когда свободно ссылаются на приложение в контексте задач, связанных с аутентификацией.
Вот еще один SO пост на аналогичную тему с хорошим ответом от Жан-Марк Приер . Он может не отвечать на все ваши конкретные вопросы, но, безусловно, попадает в концепцию.