Это 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на моем сайте здесь.
