Implementação do ponto de autenticação único

Estou construindo uma série de aplicativos da web conectados a um único ponto de autenticação. Basicamente, um usuário tenta acessar um site, se não autenticado, é redirecionado para a página de login do sistema de autenticação central. Após o login, eles são redirecionados para o aplicativo. A partir de então, se eles acessarem qualquer outro aplicativo, eles serão automaticamente conectados.

Alguns detalhes adicionais: 1) todos os aplicativos serão executados no mesmo domínio, para que eu possa usar cookies de domínio, o que facilita as coisas; 2) os usuários podem ter acesso a alguns aplicativos e não a outros, o que precisa ser levado em consideração; 3) o usuário precisa recuperar permissões específicas para cada aplicativo.

Eu implementei algo, mas não estou 100% feliz com isso. No momento, é isso que eu tenho: 1) o aplicativo Web verifica a existência de uma sessão (específica para o aplicativo) e um cookie que é um token JWT enviado pelo sistema de autenticação centralizado; 2) se o cookie não existir, eu redirecionarei para a página de login no sistema de autenticação; 3) após o login, o usuário é redirecionado para o aplicativo que passa em um token JWT; 4) o aplicativo verifica o token por meio de uma chamada da API REST ao sistema de autenticação (fazer com que essas chamadas da API REST se baseiem em um token de acesso separado); se for válido, o token JWT será salvo como um cookie e uma sessão será iniciada. usuário logado; 5) se a sessão do aplicativo expirar, ele verifica se o cookie existe e se o aplicativo faz o mesmo da etapa 4, verifica o token e reinicia a sessão; 6) ao sair, o sistema exclui o cookie, garantir que o usuário esteja desconectado de todos os aplicativos; 7) se o token expirar, o aplicativo usará o token expirado para solicitar um novo, em que a assinatura do token e outras declarações são validadas antes da emissão de uma nova, a única coisa que não é validada é a reivindicação de expiração.

Para esclarecer, a existência de uma sessão específica para o aplicativo é usada para que você não precise continuar fazendo chamadas à API REST constantemente para verificar o token. Mas, como o token foi verificado uma vez, seria seguro usar esse cookie apenas como indicador de que há uma sessão válida?

Uma coisa que não tenho certeza é que meu token precisa ter algo que indique para qual aplicativo ele se destina, pois outras chamadas à API REST podem ser feitas usando o token para obter alguns recursos específicos do aplicativo. Mas se eu obtiver um token para app1 e depois entrar no app2, o app2 dependerá do cookie gerado pelo app2. Parece que eu gostaria de ter dois tokens, um que pode ser armazenado como um cookie de domínio para indicar que o usuário está autenticado e outro que seria realmente específico do aplicativo e pode ser usado para fazer chamadas da API REST para outros aplicativos, recursos específicos.

Estou complicando demais isso ou minha linha de pensamento corresponde ao que os outros estão vendo / fazendo por aí? Ou existe uma maneira mais elegante de fazer isso? Pensei em implementar algo como Open ID, mas parece um exagero para nossas necessidades. Quero que isso seja o mais simples possível, para que eu possa documentar o processo e outras equipes de desenvolvedores possam desenvolver aplicativos que se conectem ao sistema de autenticação sem precisar de muita assistência.

Não seja louco. Ninguém em sã consciência tentaria escrever algo assim a partir do zero. Use OAuth. Você pode usar a especificação do token JWT Bearer para o token e usar escopos para determinar a qual aplicativo ou recurso o usuário tem acesso. Esta não é uma boa área para começar a reinventar a roda!

Recentemente, apenas segui um guia aqui que explica o processo de configuração da autenticação baseada em token. Uma maneira que eu posso imaginar passando alguma forma de identificação específica do aplicativo seria usando declarações.

Então você tem o site A, que o redireciona para a página do sistema de login. O site A também transmitiu alguns outros dados, como para onde levar o usuário após o login e onde está o site A. Seu sistema de autenticação analisa esses dados e, usando uma opção de alguma forma, você anexa uma reivindicação ao token de usuário que identifica o escopo atual do aplicativo.

Também para ajudar a combater o usuário a alternar entre aplicativos muito rapidamente e ainda ter acesso aos recursos do aplicativo1 enquanto estiver no app2, faça com que seus access_tokens expirem muito rapidamente. No meu site de demonstração em execução, criado usando o guia acima, o meu expira a cada minuto, assim como a implementação de um refresh_token facilita tudo. Outra etapa que pode ser útil é que, ao anexar reivindicações aos usuários, também adicione uma função ao usuário, informando que está em um site.

Em seguida, em / api / endpoint / getData do app1, defina [Authorize (Roles = "App1")], isso garantirá que apenas access_tokens que contenham uma função = App1 possa usar esse terminal em seu javascript ou em qualquer script do lado do cliente usando simplesmente faça verificações lógicas para erros, como não acessar um terminal específico e talvez o usuário precise obter um novo access_token usando o token de atualização e assim por diante.

Usando o mesmo guia que eu listei acima, siga o link e procure por isso:

var identity = new ClaimsIdentity (context.Options.AuthenticationType);

Como você pode ver, a identidade está adicionando declarações que são basicamente apenas valores que serão encapsulados dentro do access_token.

Agora, quando um usuário chama sua API da Web que possui um atributo autorizado acima, basta verificar as reivindicações dos usuários.

Um exemplo disso pode ser encontrado aqui .