Необходимо добавить автономный и сенсорный идентификатор в слой проверки подлинности Microsoft

Question

У меня есть некоторый код Xamarin C #, который аутентифицирует пользователей по каталогу компании, это в основном код, найденный в учебнике Microsoft , и сейчас мы работаем только на iOS:

App.xaml.cs

PublicClientApplicationOptions options = new PublicClientApplicationOptions()
{
    ClientId = MyAppClientId,
    TenantId = MyAppTenantId
};
var builder = PublicClientApplicationBuilder.CreateWithApplicationOptions(options);
if (!string.IsNullOrEmpty(iOSKeychainSecurityGroup))
{
    builder = builder.WithIosKeychainSecurityGroup(iOSKeychainSecurityGroup);
}
PCA = builder.Build();

ViewModel.cs

string Scopes = "User.Read";
var scopes = Scopes.Split(' ');  // Yeah, overkill

// First, attempt silent sign in
// If the user's information is already in the app's cache,
// they won't have to sign in again.
string accessToken = string.Empty;
try
{
    var accounts = await App.PCA.GetAccountsAsync();
    // PCA.GetAccountsAsync() returned [List<IAccount> #=0]
    if (accounts.Count() > 0)
    {
       var silentAuthResult = await App.PCA
          .AcquireTokenSilent(scopes, accounts.FirstOrDefault())
          .ExecuteAsync();
       accessToken = silentAuthResult.AccessToken;
    }
 }
 catch (MsalUiRequiredException)
 {
    // This exception is thrown when an interactive sign-in is required.
    // Don't need to do anything, we will notice the empty access token later
 }

 if (string.IsNullOrEmpty(accessToken))
 {
     // Prompt the user to sign-in
     var interactiveRequest = App.PCA.AcquireTokenInteractive(scopes);
     // PCA.AcquireTokenInteractive(scopes) returned Microsoft.Identity.Client.AcquireTokenInteractiveParameterBuilder
     if (authUiParent != null)
     {
        interactiveRequest = interactiveRequest
           .WithParentActivityOrWindow(authUiParent);
     }

     try
     {
        var authResult = await interactiveRequest.ExecuteAsync();
     }
     catch (MsalClientException clientException)
     {
        // When I entered the wrong password, and then hit cancel:
        // Or, when I got the "you need admin permissions" error and then hit cancel:
        /*
        interactiveRequest.ExecuteAsync() threw MsalClientException [error code "authentication_canceled"]
        Exception MsalClientException: User canceled authentication.
        */
     }
  }

Отлично работает, теперь мне нужно, чтобы он немного отличался (конечно).

1) Прежде всего, нам нужен «автономный» режим.Если пользователь хочет получить доступ к приложению в месте, где нет Интернета, мы хотим, чтобы он ввел свое имя пользователя и пароль, которые будут сравниваться с последним известным хорошим значением для этого пользователя.Прямо сейчас мы используем внутреннюю зашифрованную базу данных для хранения последних известных хороших значений для сравнения.Да, здесь есть дыра в безопасности: если мы отключили учетную запись пользователя на сервере, он может продолжать входить в систему, пока они отключают Интернет на своем мобильном устройстве, - у нас есть другие способы минимизировать эту проблему, которую я выиграл ».здесь.

2) Во-вторых, мы хотим разрешить Touch ID.Но даже если отпечаток пальца подтверждает идентификацию пользователя, мы все равно хотим проверить, был ли этот пользователь отключен на сервере, поэтому нам нужно отправить «последние известные допустимые значения» для этого пользователя на сервер для проверки.Конечно, если нет интернета, отпечатка будет достаточно.Я предполагаю, что это означает, что нам нужен экран перед вызовом AcquireTokenInteractive (), где мы даем пользователю возможность использовать Touch ID с кнопкой «Нет, я хочу ввести свое имя пользователя и пароль, пожалуйста» *

3) Наконец, даже когда у нас есть Интернет и пользователь решил не использовать Touch ID, мы хотим, чтобы он каждый раз вводил свой пароль.Мы хотим запомнить имя пользователя, недавно вошедшего в систему, и указать его, чтобы ускорить процесс, но по соображениям безопасности нам каждый раз нужен пароль.

Answer 1

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

Проблема 1: Автономный режим

Боюсь, что вы выбрали автономный режимдоступ не рекомендуется.Фактически, в MSAL мы активно смягчаем его, используя системный браузер.

Проблемы безопасности со встроенными браузерами и аутентификацией на основе форм в мобильных приложениях

Когда пользователь входит в мобильное приложение с использованием встроенного веб-просмотра или аутентификации на основе форм, это приложение может получить доступ к обычномутекстовое имя пользователя и пароль, введенные в приложение.Если пользователь загружает приложение, которое действует как законное приложение из вашей компании, эти учетные данные могут быть украдены без ведома пользователя.Это уязвимость системы безопасности, и она достаточно серьезна, чтобы Google предпринял шаг , блокируя все приложения, использующие встроенный веб-просмотр или аутентификацию на основе форм .

Системные обозреватели и аутентификация

Для предотвращения такого хранения учетных данных приложениями Google, Microsoft и другие пользователи переключились в системный браузер для сбора учетных данных.Мы используем новую способность операционной системы на мобильных устройствах для отображения веб-входа в систему поверх вашего приложения.Это кажется родным для пользователя, но на самом деле является браузером операционной системы.Поскольку ни приложение, ни Microsoft не имеют доступа к браузеру операционной системы, учетные данные, введенные вашими пользователями, находятся в безопасности.Вы увидите большинство современных приложений, использующих этот шаблон.

Это также предотвратит сохранение вами имени пользователя и пароля ваших пользователей и является специально разработанным.Пожалуйста, нигде не храните учетные данные вашего пользователя.

Как разрешить автономный доступ для приложений

Чтобы правильно реализовать ваш сценарий, есть два варианта использования приложений:

• Самым популярным шаблоном, который мы видели, является то, что приложения просят пользователя установить PIN-код для доступа к приложению при первом входе в систему или в качестве параметра в настройках.Часто пользователь просит задать PIN-код, а также Touch ID / Face ID, если Touch ID / Face ID не работает или сбрасывается.Затем пользователь использует PIN-код для доступа к приложению при каждом запуске, и это также работает, когда интернет недоступен.Этот PIN-код надежно хранится и зашифрован на устройстве.Как только Интернет станет доступным, приложение должно вызвать acquTokenSilently (), чтобы убедиться, что у пользователя все еще есть доступ к ресурсу.Если они этого не делают, вы должны предложить пользователю снова войти в систему.Многие банки и другие строго регулируемые отрасли используют этот шаблон в качестве лучшего компромисса между пользовательским интерфейсом и безопасностью.

• Следующий вариант заключается в использовании устойчивости, встроенной в библиотеку для компаний.и разработчики приложений, которые хотят, чтобы пользователь поддерживал доступ к ресурсам в случае сбоя.Мы разрешаем компаниям и разработчикам приложений настраивать срок действия токена , который больше, чем срок действия токенов по умолчанию, для токенов доступа и обновления токенов.Когда пользователь не может получить доступ к Интернету для получения нового токена доступа, продление срока действия может позволить пользователю продолжать использовать приложение.

  Это дает дополнительное преимущество работы, если ваши API-интерфейсы являются локальными для вашей среды, но поставщик удостоверений работает на основе облака или если Azure AD выходит из строя, но остальная часть Интернета работает.Ваши внутренние API будут принимать токены, чтобы ваши пользователи могли продолжать работать, даже если Интернет недоступен.И API, и ваше приложение должны будут использовать MSAL для того, чтобы ваш API соблюдал продленное время жизни, указанное в токене.Имейте в виду, у нас есть максимальное значение для токена доступа одного дня.Если ваше интернет-соединение больше, чем это, я рекомендую использовать вариант 1 выше.

Проблема 2: Проверка пользователя с помощью службы идентификации при использовании Touch ID

Этот ответ довольно прост.Просто используйте acquTokenSilently () после использования Touch ID.Это позволит получить новый токен для ресурса, для которого вы запросили токен.Для значений токенов по умолчанию токен доступа будет обновляться каждые 1 час.Я не рекомендую принудительную аутентификацию каждого Touch ID, поскольку это приведет к значительному замедлению и использованию сотовой связи.Если вы просто хотите проверить, присутствует ли пользователь, я рекомендую использовать локально сохраненный PIN-код, как описано выше.

Проблема 3: Принудительная аутентификация, если Touch ID не включен

Вы можете принудительно аутентифицироватьв любое время с помощью acquToken () с соответствующими значениями.Смотрите пример кода здесь для метода acquTokenInteractively () .

Тем не менее, небольшое количество предупреждений о юзабилити здесь:

Проблема с часто используемым паролем для проверки доступа пользователя

Служба идентификации используется для проверки, имеет ли пользовательдоступ к ресурсам, чтобы не проверять, есть ли у пользователя доступ к устройству или он все еще является пользователем предыдущего сеанса.Для этого вы должны использовать метод PIN, который я обсуждал выше, вместе с Touch ID / Face ID, если доступно.Почему?

Для истинной безопасности пароль должен сочетаться с 2FA.Исследования показывают, что 99% незаконного доступа могут быть смягчены с помощью 2FA .Однако, когда пользователь должен использовать 2FA для входа в систему, это увеличивает трение, которое он должен делать, чтобы войти в систему.На самом деле, полагаться на пароли вообще проблематично .

Ваш вариант использования, кажется, указывает на то, что вы хотите максимальный уровень безопасности для вашего приложения.Это требует использования 2FA, если это возможно.Однако переход к наилучшему состоянию безопасности для вашего приложения также затруднит использование пароля при каждом запуске приложения для ваших пользователей.

Рекомендованным шаблоном снова будет PIN или Touch ID / Face ID, а также запрос пароля после изменения доступа пользователя к ресурсу или после длительного периода времени.