Usando o OpenID para efetuar login em vários domínios: esse plano é viável? [fechadas]


8

Por exemplo:

  • Estamos executando dois sites de comunidade em dois domínios (chame-os example.come example.net).
  • Queremos poder expandir isso para mais domínios posteriormente.
  • Queremos permitir vários tipos de login (OpenID, Facebook, Twitter, nome de usuário / senha padrão).
  • Queremos que alguém que esteja logado em um site seja automaticamente conectado ao (s) outro (s).

Em outras palavras, é um pouco semelhante à rede StackExchange.

Nesse caso, esse plano funcionaria?

  • Configure example.come example.net(e quaisquer adições posteriores) como terceiros confiáveis ​​do OpenID, que aceitam id.example.orgapenas o login do OpenID .
  • Configure example.come example.netfaça uma solicitação de resposta imediata do OpenID na primeira vez que você as visitar, para que, se você estiver conectado, id.example.orgimediatamente e automaticamente faça login no site que está visitando. Eles devem definir um cookie, se você não estiver conectado, para salvá-lo em todas as solicitações de página.
  • Configure id.example.orgcomo um fornecedor e consumidor de OpenID. Também deve consumir o Facebook e outros provedores de identidade e permitir acesso padrão a nome de usuário / senha. (Vários métodos de login podem ser anexados a uma conta.)
  • No logout, basta alterar os tokens de autenticação no banco de dados. O usuário ainda terá cookies, mas eles não terão sentido. Assim, o usuário pode ser desconectado de todos os sites simultaneamente. Vários tokens de autenticação podem ser armazenados contra um usuário ao mesmo tempo (e devem ser diferentes para cada site), para que o usuário possa sair em um navegador, mas ainda estar conectado em outro. Sair sempre sai de todos os sites.

O único problema que posso ver com o acima é este:

  • Alguém visita example.com. Um cookie "não conectado" está definido.
  • Zie então entra example.net. Idem.
  • Zie faz login e continua navegando example.net.
  • O Zie volta para example.come, por causa do cookie "não conectado", não é verificado id.example.orge, portanto, não está conectado.
  • No entanto, assim que o zie clicar no botão "efetuar login", o zie será conectado.

Eu não acho que isso seja um grande problema.

No geral, acho que é um sistema muito bom. Eu só gostaria de vê-lo revisado. Existem problemas que eu não previ? Seria de buggy ou lento? StackExchange usa um método muito diferente. Presumo que eles tenham uma boa razão para isso?


1
isso seria melhor solicitado em webmasters.stackexchange.com ?
Doug T.


Acho que sim por essa ideia! Acho que não deveria ter sugerido isso.
Doug T.

Respostas:


0

O tipo móvel usa um método de login muito semelhante ao que você descreve. Pessoalmente, não me importo, mas há momentos em que a apresento a um cliente e ele pode ajudar, mas pergunta: "o que exatamente está acontecendo aqui?"

O projeto pelo qual fiquei mais intrigado com relação à criação de um sistema de login coerente é o Google Identity Toolkit . A experiência do usuário é excelente e a facilidade com que parece ser implementável é muito atraente.


1
As propriedades do Google que não são hospedadas via google.com(YouTube, por exemplo) também usam esse tipo de fluxo de trabalho. (Se eu visitar o YouTube, entrar na minha conta do Google no GMail e depois voltar ao YouTube, continuarei desconectado até clicar em "efetuar login", quando a página atual será atualizada
novamente
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.