Должен ли я явно не использовать стандартный URL-адрес с аутентификацией MSAL? - PullRequest
0 голосов
/ 03 октября 2018

Вся документация MSAL требует, чтобы я использовал префикс, такой как msalGUID:///, при аутентификации обратно на локальное устройство.

Затем есть URL-адрес oddball urn:ietf:wg:oauth:2.0:oob, который по умолчанию отображается в Портал MSAL.

Поскольку каждый URL-адрес, который я перечисляю, в моем приложении, по сути, является бэкдором, я хочу понять преимущества безопасности каждого варианта.

  • Почему я должениспользовать документированную схему msalGUID://?
  • Не следует ли использовать универсальную ссылку iOS / полный URL-адрес?
  • В чем преимущества urn:ietf:wg:oauth:2.0:oob и https://login.live.com/oauth20_desktop.srf?
  • Что следует знать о взаимодействии с Microsoft Authenticator, что, вероятно, зависит от этого?

1 Ответ

0 голосов
/ 03 октября 2018

Фон

Существует несколько векторов атак и юзабилити, которые учитываются при рассмотрении URI перенаправления, которое будет использовать ваше приложение.

Во-первых, будет ли ваше приложение выполнять вход пользователей из агента авторизации, который не помещен в изолированную программную среду вашего приложения.Если вы используете MSAL, то ответ почти всегда да (если вы явно не решили использовать веб-представления в приложении).

Случаи, которые следует учитывать

Если это так, то у вас есть дваРассмотрим следующие случаи: случайные коллизии URI перенаправления (проблема с удобством использования) и вредоносные приложения, умышленно пытающиеся перехватить пользователя, перенаправляемого обратно в ваше приложение (проблема безопасности).

Случай 1: Наивные приложения

Для решения первого вопроса MSAL выбрала msal<ClientID>://auth, поскольку она уникальна для каждой регистрации приложения.В этом формате много случайности (которая теряется при urn:ietf:wg:oauth:2.0:oob), что предотвращает сценарий, в котором несколько приложений на устройстве прослушивают один и тот же URI и «случайно» получают ответ.Для пользователя это крайне разочаровывает и может повлиять на их опыт работы с приложением.Чтобы обобщить рекомендации по решению этой проблемы, используйте очень случайный URI, который позволяет избежать случайного столкновения с другими приложениями.

Случай 2: Вредоносные программы

Для решения последних MSAL реализует Протокол Proof Key для Code Exchange (PKCE) для устранения этого вектора атаки.Чтобы расширить этот сценарий, он аналогичен приведенному выше сценарию, за исключением того, что приложение намеренно захватило ответ и намеревается обменяться кодом авторизации от вашего имени.С PKCE только приложение, которое инициировало запрос, может обмениваться кодом авторизации.

Подведение итогов ответов

Чтобы быстро ответить на ваши вопросы, 1. Обложка выше.2. Если вы знакомы с универсальными ссылками и с тем, как настроить необходимые шаги, это может быть хорошим вариантом для проверки того, что регистрация вашего приложения используется только вами.3. Они предназначены для приложений, использующих веб-представления внутри приложения, где существуют более строгие гарантии безопасности, связанные с тем, что оно не покидает приложение.4. MSAL в настоящее время не интегрируется в Authenticator для выполнения запросов аутентификации.Когда это произойдет, приложения, вероятно, будут обязаны выполнить расширенную регистрацию, связанную с URI перенаправления, аналогичную требованиям ADAL .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...