El AccountManager
es bueno por las siguientes razones:
- Primero es almacenar múltiples nombres de cuenta con diferentes niveles de acceso a las funciones de la aplicación en un solo tipo de cuenta. Por ejemplo, en una aplicación de transmisión de video, uno puede tener dos nombres de cuenta: uno con acceso de demostración a un número limitado de videos y el otro con acceso de mes completo a todos los videos.
Accounts
Sin embargo, esta no es la razón principal para usarlo , ya que puede administrarlo fácilmente en su aplicación sin la necesidad de este aspecto elegante Accounts
...
- La otra ventaja de usar
Accounts
es deshacerse de la autorización tradicional con nombre de usuario y contraseña cada vez que el usuario solicita una función autorizada, porque la autenticación se realiza en segundo plano y se le solicita al usuario su contraseña solo en ciertas condiciones, lo que Llegaré a eso más tarde.
- El uso de la
Accounts
función en Android también elimina la necesidad de definir el propio tipo de cuenta. Probablemente haya encontrado las aplicaciones que usan cuentas de Google para obtener autorización, lo que ahorra la molestia de crear una nueva cuenta y recordar sus credenciales para el usuario.
Accounts
se puede agregar de forma independiente a través de Configuración → Cuentas
- La autorización de usuario multiplataforma se puede gestionar fácilmente mediante
Accounts
. Por ejemplo, el cliente puede acceder al material protegido al mismo tiempo en su dispositivo Android y PC sin la necesidad de inicios de sesión recurrentes.
- Desde el punto de vista de la seguridad, el uso de la misma contraseña en cada solicitud al servidor permite posibles escuchas en conexiones no seguras. El cifrado de contraseña no es suficiente aquí para evitar el robo de contraseña.
- Finalmente, una razón importante para usar la
Accounts
función en Android es separar a las dos partes involucradas en cualquier negocio que dependa del Accounts
llamado autenticador y propietario del recurso, sin comprometer las credenciales del cliente (usuario). Los términos pueden parecer bastante vagos, pero no te rindas hasta que leas el siguiente párrafo ...…
Permítanme detallar esto último con un ejemplo de una aplicación de transmisión de video. La Compañía A es titular de un negocio de transmisión de video en contrato con la Compañía B para proporcionar a sus miembros ciertos servicios de transmisión premium. La empresa B emplea un método de nombre de usuario y contraseña para reconocer a su usuario. Para que la Compañía A reconozca a los miembros premium de B, una forma sería obtener la lista de ellos de B y utilizar un mecanismo similar de coincidencia de nombre de usuario / contraseña. De esta manera, el autenticador y el propietario del recurso son los mismos (Compañía A). Además de la obligación de los usuarios de recordar una segunda contraseña, es muy probable que establezcan la misma contraseña que el perfil de su Compañía B para usar los servicios de A. Esto obviamente no es favorable.
Para mitigar las deficiencias anteriores, se introdujo OAuth. Como estándar abierto para la autorización, en el ejemplo anterior, OAuth exige que la autorización sea realizada por la Compañía B (autenticador) emitiendo un token llamado Token de acceso para los usuarios elegibles (terceros) y luego proporcionando a la Compañía A (propietario del recurso) la ficha Entonces, ninguna ficha significa que no hay elegibilidad.
He elaborado más sobre esto y más AccountManager
sobre mi sitio web aquí.