Como migrar o webapp herdado existente para usar o OAuth2

Atualmente, tenho um webapp monolítico legado de 15 anos com quase 1 milhão de usuários, usando um sistema doméstico de autorização e autenticação: JAAS, nomes de usuário e armazenamento de pwds em um banco de dados com hash de senha básico, algumas perguntas de verificação pessoal 2FA (com diferentes algoritmos de hash, etc).

Estarei revisando o aplicativo nos próximos 12 a 18 meses, principalmente focado na interface do usuário, mas também atualizando lentamente as partes subjacentes (atualizando para Spring, Spring Security, etc.). Nesse projeto, decidimos abordar a atualização da interface do usuário módulo a módulo; disponibilizar cada módulo assim que estiver concluído; uma oportunidade perfeita para dividir o monólito em aplicativos da web individuais (todos mantendo o mesmo design de UX).

O ponto em que estou tentando planejar isso é no nível de autenticação e autorização. Preciso de uma solução transversal que abranja todos os módulos, para que, quando um usuário seja direcionado de um aplicativo da web para outro, seja uma transição perfeita - eles nem saberão que estão em aplicativos da web diferentes. OAuth2 parece a solução perfeita.

Estou preso tentando entender como integrar isso. Preciso criar meu próprio servidor OAuth2 personalizado? Isso me parece uma péssima idéia. Mas como eu:

1. migrar todas as minhas contas de usuário e processo de autorização para um servidor OAuth2 de terceiros
2. personalizar a aparência para corresponder ao resto do meu aplicativo (não sei com que facilidade / provável isso será)
3. impedir o pop-up típico "O aplicativo XYZ gostaria de permissão para acessar sua conta ..." ao se conectar através de um servidor de terceiros? (ex: Google OpenID, Facebook, etc.).

Meu objetivo é fornecer uma transição perfeita para o usuário do estado atual para o novo estado, mas fornecendo a capacidade de criar aplicativos da web separados que todos autenticam e autorizam fora do aplicativo da web.

Divulgação : Sou engenheiro da Auth0 .

Depende de um ponto importante ... você precisa decidir se:

1. você deseja gastar diretamente uma quantidade considerável de tempo (e indiretamente gastar dinheiro) na construção e / ou manutenção de seu próprio provedor de identidade e servidor de autorização
2. ou você prefere gastar dinheiro diretamente e usar um provedor de autenticação de terceiros como o Auth0.

Ambas as opções são perfeitamente viáveis ​​do ponto de vista de seus requisitos funcionais. Com o desenvolvimento personalizado, você tem total controle da funcionalidade que decide dar suporte, portanto, focarei parte da resposta em como o Auth0 pode responder aos requisitos listados .

No entanto, antes de avançar para isso, independentemente da sua decisão, para autenticação, você deve se concentrar no OpenID Connect em vez do OAuth2. O último será mais aplicável se você planeja também ter APIs no mix e não apenas dividir o monólito em aplicativos Web separados.

Como migrar usuários existentes para um sistema baseado em Auth0?

Você pode optar por continuar usando seu banco de dados e confiar no Auth0 para fornecer toda a conformidade com os protocolos relacionados à autenticação que possa precisar usar ou pode migrar seus usuários para os bancos de dados gerenciados pelo Auth0 e parar de se preocupar com o armazenamento e a validação de senhas.

Se você preferir continuar usando seu banco de dados, consulte Autenticar usuários com nome de usuário e senha usando um banco de dados personalizado

Os aplicativos geralmente confiam nos bancos de dados do usuário para autenticação. O Auth0 permite conectar-se facilmente a esses repositórios e usá-los como provedores de identidade, preservando as credenciais do usuário e fornecendo muitos recursos adicionais.

_{(Os documentos se referem ao MySQL apenas como exemplo, outros mecanismos de banco de dados são suportados)}

Por outro lado, você pode mover facilmente as credenciais do usuário para os bancos de dados Auth0, aproveitando o processo de migração descrito em Migrar usuários para o Auth0

O Auth0 suporta a migração automática de usuários para o Auth0 a partir de uma conexão de banco de dados personalizada. Esse recurso adiciona seus usuários ao banco de dados Auth0, um de cada vez, à medida que cada um efetua login e evita solicitar que os usuários redefinam suas senhas, tudo ao mesmo tempo.

Você também pode criar todos os seus usuários no Auth0 por meio da API de gerenciamento, se preferir que todos eles comecem a usar nosso algoritmo de hash de senha de uma só vez. Isso tem o efeito colateral de exigir que os usuários redefinam sua senha.

Como continuar usando a autenticação em duas etapas personalizada (perguntas de verificação)?

O pipeline de autenticação fornecido pelo Auth0 é totalmente personalizável através do uso de regras . Isso significa que, mesmo que você não tenha implementado nada relacionado a protocolos, ainda pode ajustar os pequenos detalhes de como a autenticação acontece no seu aplicativo.

Isso inclui a possibilidade de continuar usando as perguntas de verificação existentes como uma maneira de executar um processo de autenticação em duas etapas, em que o usuário fornece uma senha inicial verificada pelo Auth0 e, em seguida, você solicita informações adicionais a partir de uma regra personalizada. (as regras são apenas Javascript, portanto, as possibilidades são infinitas)

No entanto, você também pode optar por descartar as perguntas de verificação e seguir com o Auth0 Guardian como uma maneira de aumentar a segurança do processo de autenticação.

Como personalizar a aparência da interface do usuário de autenticação?

Com o Auth0, você pode ter uma interface de usuário de autenticação limpa rapidamente, aproveitando as páginas de login padrão ou os widgets de autenticação como o Lock . Tudo isso suporta algum grau de personalização e você sempre pode decidir fazer sua própria interface do usuário e aproveitar as bibliotecas Auth0 de nível inferior ( Auth0.js ) que não fazem restrições à interface do usuário.

Para mais informações sobre personalização:

• Personalizando a aparência do Lock 10
• Como personalizar páginas hospedadas

Como evitar páginas de consentimento explícito?

Você pode usar o Auth0 como um provedor de identidade para fins de autenticação e também como um servidor de autorização OAuth2 (atualmente disponível apenas na região dos EUA) para suas APIs.

Como provedor de identidade, você não precisa se preocupar com as páginas de consentimento, o usuário se autentica com suas credenciais gerenciadas pelo Auth0 e depois é redirecionado para o seu aplicativo - é isso.

No cenário do OAuth2 como serviço, quando o consentimento está ativado, o roteiro inclui permitir ignorar as páginas de consentimento para determinados aplicativos.

Em uma nota final, esse parece ser um projeto muito interessante e desafiador que você chegou lá, portanto, boa sorte, independentemente da sua decisão final.

Eu já passei por algo semelhante em um trabalho anterior, quando tive que reimplementar o sistema de autenticação de um aplicativo herdado. Implementamos nosso próprio provedor de identidade e servidor de autorização e, para ser sincero, ainda sinto que podemos ter esquecido algo realmente essencial.

Eu acho que esse é o maior problema com a rolagem de sua própria segurança; haverá ocasiões em que os prazos impõem atalhos e a segurança não é realmente uma boa área para criar atalhos.

Se tiver mais perguntas, entre em contato se achar que posso ser útil.