AccountManager хорош по следующим причинам:
- Сначала необходимо сохранить несколько имен учетных записей с различными уровнями доступа к функциям приложения под одним типом учетной записи. Например, в приложении для потоковой передачи видео у одного может быть два имени учетной записи: одно с демонстрационным доступом к ограниченному количеству видео, а другое с полным доступом к месяцам ко всем видео. Однако это не главная причина использования
Accounts, поскольку вы можете легко управлять этим в своем приложении, не прибегая к этой необычно выглядящей вещи Accounts. *
- Другое преимущество использования
Accounts состоит в том, чтобы избавляться от традиционной авторизации с использованием имени пользователя и пароля каждый раз, когда пользователь запрашивает авторизованную функцию, поскольку аутентификация происходит в фоновом режиме, а у пользователя запрашивается его пароль. только в определенном состоянии, которое я доберусь до него позже.
- Использование функции
Accounts в Android также устраняет необходимость определения собственного типа учетной записи. Вероятно, вы сталкивались с приложениями, использующими учетные записи Google для авторизации, что избавляет от необходимости создавать новую учетную запись и запоминать ее учетные данные для пользователя.
Accounts можно добавить независимо через Настройки → Аккаунты - Межплатформенной авторизацией пользователей можно легко управлять с помощью
Accounts. Например, клиент может одновременно получить доступ к защищенному материалу на своем устройстве Android и ПК без необходимости повторных входов в систему.
- С точки зрения безопасности, использование одного и того же пароля в каждом запросе к серверу допускает возможное прослушивание в незащищенных соединениях. Для предотвращения кражи пароля здесь недостаточно шифрования пароля.
- Наконец, важной причиной использования функции
Accounts в android является разделение двух сторон, вовлеченных в любой бизнес, зависящий от Accounts, так называемого аутентификатора и владельца ресурса, без ущерба для учетных данных клиента (пользователя) , Условия могут показаться довольно расплывчатыми, но не сдавайтесь, пока не прочитаете следующий абзац ... ?
Позвольте мне подробно остановиться на последнем примере приложения для потоковой передачи видео. Компания A является владельцем бизнеса по потоковому видео, заключившего договор с компанией B на предоставление ее отдельным членам премиальных потоковых услуг. Компания B использует метод имени пользователя и пароля для распознавания своего пользователя. Для компании A, чтобы распознать премиум-членов B, одним из способов было бы получить их список от B и использовать аналогичный механизм сопоставления имени пользователя и пароля. Таким образом, аутентификатор и владелец ресурса совпадают (Компания A). Помимо обязательства пользователей запоминать второй пароль, весьма вероятно, что они устанавливают тот же пароль, что и профиль их компании B для использования услуг от A. Это явно не выгодно.
Чтобы устранить вышеуказанные недостатки, был введен OAuth. В качестве открытого стандарта для авторизации в приведенном выше примере OAuth требует, чтобы авторизация была выполнена Компанией B (аутентификатор), выпуская некоторый токен под названием Access Token для соответствующих пользователей (третье лицо), а затем предоставляя Компании A (владельцу ресурса) знак Так что отсутствие знака означает отсутствие права на участие.
Я подробнее об этом и подробнее о AccountManager на моем сайте здесь.
