O AccountManageré bom pelos seguintes motivos:
- O primeiro é armazenar vários nomes de conta com diferentes níveis de acesso aos recursos do aplicativo em um único tipo de conta. Por exemplo, em um aplicativo de streaming de vídeo, um pode ter dois nomes de conta: um com acesso demo a um número limitado de vídeos e outro com acesso mensal a todos os vídeos. No
Accountsentanto, esse não é o principal motivo de uso , já que você pode gerenciar isso facilmente no seu aplicativo sem a necessidade dessa aparência atraente Accounts….
- A outra vantagem do uso
Accountsé livrar-se da autorização tradicional com nome de usuário e senha cada vez que um recurso autorizado é solicitado pelo usuário, porque a autenticação ocorre em segundo plano e o usuário é solicitado a fornecer sua senha apenas em determinadas condições, o que Eu vou chegar mais tarde.
- O uso do
Accountsrecurso no android também elimina a necessidade de definir o próprio tipo de conta. Você provavelmente já encontrou os aplicativos usando as Contas do Google para autorização, o que evita o incômodo de criar uma nova conta e lembrar suas credenciais para o usuário.
Accounts pode ser adicionado independentemente por meio de Configurações → Contas- A autorização de usuário de plataforma cruzada pode ser facilmente gerenciada usando
Accounts. Por exemplo, o cliente pode acessar o material protegido ao mesmo tempo em seu dispositivo Android e PC sem a necessidade de logins recorrentes.
- Do ponto de vista da segurança, o uso da mesma senha em todas as solicitações ao servidor permite uma possível interceptação em conexões não seguras. A criptografia de senha não é suficiente aqui para impedir o roubo de senhas.
- Finalmente, uma razão importante para usar o
Accountsrecurso no android é separar as duas partes envolvidas em qualquer negócio dependente Accounts, chamado autenticador e proprietário do recurso, sem comprometer as credenciais do cliente (usuário). Os termos podem parecer bastante vagos, mas não desista até ler o parágrafo a seguir… 😉
Deixe-me elaborar sobre este último com um exemplo de aplicativo de streaming de vídeo. A empresa A é detentora de uma empresa de streaming de vídeo contratada com a empresa B para fornecer a seus membros certos serviços premium de streaming. A empresa B emprega um método de nome de usuário e senha para reconhecer seu usuário. Para a Empresa A reconhecer os membros premium de B, uma maneira seria obter a lista deles de B e utilizar um mecanismo de correspondência de nome de usuário / senha semelhante. Dessa forma, o autenticador e o proprietário do recurso são os mesmos (Empresa A). Além da obrigação dos usuários de lembrar uma segunda senha, é muito provável que eles definam a mesma senha do perfil da empresa B para usar os serviços de A. Isso obviamente não é favorável.
Para atenuar as deficiências acima, o OAuth foi introduzido. Como padrão aberto para autorização, no exemplo acima, o OAuth exige que a autorização seja feita pela Empresa B (autenticador) emitindo algum token chamado Token de Acesso para os usuários qualificados (terceiros) e fornecendo à Empresa A (proprietário do recurso) o token. Portanto, nenhum token significa nenhuma elegibilidade.
Eu elaborei mais sobre isso e mais AccountManagerno meu site aqui.
