API Identity: Um Exemplo Prático

API Identity é um novo tipo de API criada para facilitar a autenticação por Password. Esta API substitui o OAuthDirectory e permite modificar e tratar as chamadas feitas para os servidores de autenticação.

Neste artigo, veremos passo a passo a configuração de um exemplo de API Identity para que no momento de realizar sua configuração você possa associar melhor os detalhes com a sua realidade.

Qual a finalidade?

O API Identity, assim como sua funcionalidade antecessora o Oauth directory, é uma configuração que busca centralizar provedores de autenticação internos para suas APIs.

APIs Identities possuem em seu corpo, APIs que possuem os Interceptors OAuth e ou AccessToken Validation, com a opção "Password" habilitada. Quando uma APP que utiliza alguma dessas APIs associadas, ao requerir um Access Token do tipo Password, será realizado uma requisição para a API Identity, que tratara a chamada e enviará pra o endPoint de autenticação.

 

Configurando o API Identity

O API Identity possui a configuração e comportamento parecido com uma API normal, trabalhando também com environments e sendo possível realizar as segregações lógicas das chamadas, portanto se o fluxo POST /access-token for feito para o environment produção o API Identity deve estar com deploy habilitado em produção.

Neste exemplo prático iremos configurar a API Identity para autenticar a API Eventos que possui um provedor próprio para seus usuários.

Para isso, primeiramente criamos a API Eventos que possui o interceptor oauth autorizando o grant type password

​​

Em seguida temos que configurar o API Identity.

Para simular dois provedores (um para produção e outro para desenvolvimento) é preciso configurar o endereço dos provedores nos respectivos environments.

Em produção:

Em desenvolvimento:

Com este detalhe configurado no environment basta criar o API Identity.

No primeiro passo, criamos o API Identity com as mesmas informações que uma API e vinculada aos environments de produção e desenvolvimento.

No destination vamos inserir a variável criada nos environments, assim o Back-End provedor de autorização será chamado dinamicamente de acordo com o environment. Uma observação importante, o fluxo da API Identity deve ser criado no fluxo principal dela  Resouses (all) Operations (all).

Na próxima tela, temos a configuração que difere o API Identity de uma API normal, neste ponto selecionamos para qual API este API Identity irá prover autenticação.

 

Tendo isso configurado o fluxo de criação de access token (POST /access-token)  irá efetuar uma chamada para o API identity validar as credenciais (todas as informações de body são enviadas ao API Identity), todos os interceptors no fluxo do API identity são executados como uma API.

No nosso exemplo realizando a chamada para Produção será feito a chamada para o provedor de autenticação de produção

curl -X POST \
https://api-suporte.sensedia.com/oauth/access-token \
-H 'Authorization: Basic Mjc0OTM2ZmItZGJmMy0zMzRjLWE1OWQtNTRmYjkxMTA0OThiOjYxMGQ3OGZlLWRiZDQtMzQxYi04OTRlLTYyYjA2ZmZkZDg4Yw==' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-H 'Postman-Token: cd278e57-3ee5-4e6e-987a-da395e7cb4b9' \
-d '{
"grant_type": "password",
"credencial": "user0598",
"codLiberacao": "P@ssk3y963"
}'

Confirmamos no trace a chamada para produção

 

E a chamada em dev para o provedor de desenvolvimento

curl -X POST \
https://api-suporte.sensedia.com/dev/oauth/access-token \
-H 'Authorization: Basic Mjc0OTM2ZmItZGJmMy0zMzRjLWE1OWQtNTRmYjkxMTA0OThiOjYxMGQ3OGZlLWRiZDQtMzQxYi04OTRlLTYyYjA2ZmZkZDg4Yw==' \
-H 'Cache-Control: no-cache' \
-H 'Content-Type: application/json' \
-H 'Postman-Token: 015e4172-e540-4764-aeec-f3b3b03de173' \
-d '{
"grant_type": "password",
"credencial": "user08547",
"codLiberacao": "P@ssk3y412"
}'

Confirmamos no trace a chamada para dev

 

Podemos ver pelas chamadas realizadas que os valores de credenciais são diferentes e os campos "credencial" e "codLiberacao" são campos que o backend valida, podendo pelo API Identity ser customizados conforme for a necessidade.

Retrocompatibilidade

Com relação a retrocompatibilidade temos os seguintes pontos a considerar. 

Visto que o API Identity vem para substituir o Oauth Directory temos alguns pontos de atenção para que as APIS que utilizam o Oauth Directory não fiquem indisponíveis.

Para as novas APIS criadas (criadas a partir do momento que o API Identity foi disponibilizado), de inicio, o fluxo password é feito pelo antigo oauth directory, para que nos novos desenvolvimentos não fiquem totalmente dependentes do API Identity. Uma vez que qualquer API (nova) passe a utilizar o API Identity será utilizado apenas o API Identity. 

Para as APIS que existiam antes do API Identity ser disponibilizado, será executado o fluxo pelo oauth directory, mesmo a API sendo relacionada a um API Identity. Para que estas APIS utilizem o API identity é preciso remover a configuração de oauth directory.



Nossa sugestão para realizar a migração de uma API criada antes da funcionalidade é criar um clone para homologação, este por se tratar de uma nova API irá realizar o fluxo pelo API Identity assim que associado a um.

Conclusão

Nossa ideia é apresentar de forma mais simplificada como funciona o API Identity e qual a sua aplicação em um exemplo prático. 

Com relação ao Oauth Directory o API Identity nos traz de uma forma muito similar a configuração de APIS já conhecida uma governança completa e controle sobre o fluxo de autorização password, atendendo a vários requisitos que o Oauth Directory não atendia, como por exemplo autenticação por vários provedores de autenticação, controle de payload e rastreabilidade das chamadas.

Tem mais dúvidas? Envie uma solicitação

Comentários

Desenvolvido por Zendesk