Neste post vou descrever os novos esquemas de autenticação que estamos suportando no GAM.

GAM significa GeneXus Access Manager e é uma funcionalidade que está incorporada ao GeneXus para resolver problemas de autenticação e autorização de suas aplicações.

Para apresentar as ferramentas, nos perguntaremos: O que está fazendo o mundo da segurança e da autenticação?

Na pesquisa Auth0, que apresenta o que é oferecido no mercado em relação aos esquemas de autenticação, surgiram os seguintes dados:

• 28% estão oferecendo autenticação multifator, que é o mesmo que autenticação de dois fatores, isso significa que o usuário tem que validar dois fatores para entrar no aplicativo. Geralmente o primeiro fator é a senha e o segundo é um número randômico ou algo que é enviado por e-mail ou SMS.
• 45% estão oferecendo single sign-on por meio de serviços existentes. Isso é muito bom para os usuários finais, já que as empresas estão dando a possibilidade de ter um único nome de usuário e senha, permitindo que eles acessem todos os seus aplicativos ou produtos.
• 21% estão oferecendo autenticação biométrica, que ocorre principalmente em aplicativos nativos em dispositivos móveis.
• Então temos os 31% que estão oferecendo autenticação através das redes sociais. Os mais usados ​​são Google, Facebook e Twitter.
• E 20% estão permitindo que os usuários entrem sem ter uma senha. Este mecanismo faz com que o usuário não tenha uma senha para entrar no aplicativo, basta digitar um e-mail e o sistema envia um e-mail com o código de acesso para acessar aquele aplicativo. Este código é válido apenas uma vez e por um período de tempo muito curto.
  

O que GeneXus oferece para resolver todos esses esquemas de autenticação?

Vimos o que GeneXus tem para configurar cada um destes esquemas de autenticação:

• OAuth 2.0, 
• OpenID Connect, 
• One-Time Password, y
• Two-Factor Authentication. 

Protocolo OAuth 2.0

Oauth 2.0 é o protocolo mais usado entre os diferentes fornecedores de identidade; Entre eles estão Google, Facebook, Microsoft, etc.

Como funciona o protocolo OAuth 2.0? Vamos dar um exemplo pontual: temos um usuário final que vai navegar em um aplicativo e na Internet temos 3 aplicativos (veja a imagem abaixo). Esses aplicativos são 3 bases de conhecimento independentes com seu próprio banco de dados e cada um possui GAM ativado.

Os dois aplicativos dos extremos são os Clientes e o aplicativo central é o Identity Provider. Chamei os clientes de “Download Center”, e o outro de site “GeneXus.com”, e o Identity Provider poderia ser a “GeneXus Account”.

Quando o usuário vai acessar este aplicativo, ele sabe que está autenticado com um o Identity Provider, para o qual o aplicativo redireciona para o Identity Provider., ele exibe sua tela de Login.

Este é um dos pontos fortes, as credenciais são inseridas apenas no Identity Provider, não são inseridas nos clientes. O Identity Provider é responsável por validar essas credenciais e se validar corretamente, ele responde ao cliente, e o cliente já mostra a tela do usuário autenticado.

Agora, o protocolo OAuth é um pouco mais complexo que isso, aqui entre o Identity Provider e o Cliente há mais troca de informações. O que o Identity Provider responde ao Cliente é o que é chamado de access_code e o cliente com esse código solicita o token e após obter o token solicita as informações do usuário desse token.

Depois de ter todas essas informações em seu banco de dados local, o usuário é criado ou atualizado, uma sessão e um token local são criados e a autenticação termina aí. Por trás de tudo isso acontece o padrão OAuth 2.0.

O que acontece se navegando por este aplicativo eu for acessar outro aplicativo que também se autentique com o mesmo Identity Provider?

O que vai acontecer é que quando o Identity Provider chegar, ele detecta que já está autenticado e já responde diretamente ao access_code desta aplicação; aqui o usuário também é criado ou atualizado e depois redirecionado para a tela com o usuário autenticado. Veja que não só centraliza a autenticação, mas com isso já temos um single sign-on entre todos os aplicativos da empresa.

Quanto trabalho é necessário para configurá-lo em nossos aplicativos?

Com GeneXus, o bom é que você não precisa programar nada, é só configurar.

Neste vídeo explico o passo a passo para a configuração de segurança com GAM.

OpenID Connect

Open ID Connect se está transformando en el protocolo más común utilizado entre todos los proveedores de identidades. Eso se da porque Open ID Connect corre dentro de Oauth 2.0 y digamos que lo termina de estandarizar, porque Oauth 2.0 no tiene en el estándar cómo obtener la información del usuario.

Entonces, lo que ustedes configuraban en este tab de User Information ahora, si utilizan Open ID Connect, no es necesario configurarlo. Pueden dejar esa URL en blanco. Lo que nos pasaba hasta hoy es que el User Information cada Identity Provider devolvía los datos que el Identity Provider quería.

O Open ID Connect está se transformando no protocolo mais comum usado entre todos os provedores de identidade. Isso ocorre porque o Open ID Connect roda dentro do Oauth 2.0 e digamos que termina de padronizá-lo, pois o Oauth 2.0 não tem no padrão como obter as informações do usuário.

Então, o que você configurou nesta tab de User Information agora, se você usa o Open ID Connect, não é necessário configurá-lo. Eles podem deixar esse URL em branco. O que aconteceu conosco até hoje é que a User Information de cada Identity Provider retornaram os dados que o Identity Provider desejava.

Agora existe um padrão e você pode configurá-lo no setor de Autorização. Ao entrar lá, eles terão a opção de habilitar esse protocolo Open ID Connect e se simplesmente o habilitarem, o GAM começa a armazenar uma nova propriedade que retorna ao Identity Provider chamada ID Token. O GAM armazena e disponibiliza para você usar. Se eles precisarem fazer uma solicitação a esse Identity Provider, eles poderão usá-lo. Mas para habilitar 100% do protocolo, eles teriam que habilitar a validação, onde diz Validate IDToken. O ID Token é um token da Web JSON assinado pelo provedor. É por isso que aqui eles têm que confirmar quem é o provedor do ID Token e eles têm que ter em seu servidor local, em um caminho local do servidor, é um certificado público desse provedor.

Com isso você obtém aquele JSON Web Token que, entre outras coisas, possui as informações do usuário autenticado.

One-Time Password (OTP)

É um novo tipo de autenticação GAM, assim como eles podem configurar a autenticação com Google ou Facebook.

Lembre-se de que One Time Password é uma senha fornecida a você e você pode usá-la apenas uma vez por um curto período de tempo. Você pode escolher o tamanho, se a chave gerada for apenas números ou se quiser que seja alfanumérica.

Você pode selecionar quanto tempo de vida esse código gerado automaticamente tem e muitas outras propriedades de segurança.

Se você estiver especificamente interessado neste método de autenticação, sugiro esta leitura: One Time Passwords (OTP) e Second Factor Authentication (2FA)

Two-Factor Authentication

Também é conhecida como Autenticação Multifator, em ambos os casos serão sempre validados dois fatores.

Normalmente, uma senha é validada primeiro. Temos disponíveis em todos os tipos de autenticação que não fazem redirecionamento para autenticar. Esses tipos de autenticação são: Local, Custom, External Webservice e GAMRemoteRest.

Neles você verá essas novas propriedades onde poderá habilitar essa funcionalidade. Então o que eles vão escolher é qual é o segundo tipo de autenticação que eles vão usar. Eles serão os Tipos de autenticação One Time Password que você definiu neste mesmo GAM. Você define como deseja que esse segundo tipo de autenticação seja gerado e também poderá configurar o tempo, a vida útil que o usuário terá para validar os dois fatores de autenticação. Neste caso, se ele ultrapassar 900 segundos para validar os dois fatores, ele deverá revalidar o primeiro fator.

Outra propriedade interessante é que você pode marcar se deseja que todos os usuários do seu aplicativo sejam forçados a fazer Autenticação de Dois Fatores ou se não marcar, é que cada usuário pode selecionar se deseja ou não usar esse mecanismo de autenticação.

Não perca este vídeo 2FA, senha de uso único, OpenID: Tudo sobre os novos esquemas de autenticação, onde aprofundo todos esses conceitos e dou algumas dicas técnicas para que você possa desenvolver seus aplicativos integrados entre si e integrados a todos os esquemas de autenticação existente. Tudo usando GeneXus 17!