Следвам ръководството на защита на моя API с помощта на MS ID. Работи както се предполага и извежда кода на състоянието 401, неоторизиран. Но ето каква е работата...
Как да упълномощя?! Ръководството не споменава нищо за това и следващата стъпка се отнася изцяло до нова тема. Говоря за изпращане на обаждане чрез Swagger или Postman (вероятно последното, тъй като е по-лесно да предоставите идентификационни данни).
Изходният код е елегантен и спретнато пакетира предизвикателството и други подобни (подобно на ръководството на защита на приложение с помощта на MS ID. Уговорката е това усещане за черна кутия, където нещата работят, но аз съм не съм сигурен точно как. В случай на уеб приложение, това е малко магия, но има GUI и това води до това принципалът да получи самоличност, зададена от Azure AD.
Но как да направя това в случая на API? Изпълнимо ли е изобщо? Трябва да е така, в противен случай няма смисъл да разкриваме API като начало. Бих искал да демонстрирам достъпа и отхвърлянето от Posty (или Swaggy, ако не е твърде сложно), преди да продължа да се занимавам с MS ID защита, базирана на SPA.
Има ръководство в MSDN как да получите токена. Заявката включва следните заглавки (x-www-urlencoded).
grant_type=client_credentials
client_id=e91eecbf-680e-4e35-ac43-c93456a0a44e
client_secret=ljkh()/¤#%jL9jlk< /em>
Той изпълнява GET on
https://login.microsoftonline.com/6d9c4356-1774-49f3-a6be-ff4c2ec4f2f4/oauth2/token
и произвежда токен за достъп за посочения ресурс (в техния случай автобусна услуга). Търся нещо точно като това, но така че потребителят да трябва да предостави своите идентификационни данни. Токенът за отговор трябва да съдържа GUID (или поне имейл) за потребителя, с други думи.
Намерих подобен въпрос, но се отнася до случай B2C (който не съм сигурен, че е подходящ за мен) и също така не обяснява как да получа клиентския API ID за пощальон. Виждал съм също този отговор, но той се отнася до графичен API, който не е уместен в моя случай.
