Usando o Postman para testar o OAuth2.0 do repositório InterSystems FHIR - Parte 1

Olá a todos, sou eu novamente para compartilhar o que ando estudando recentemente.😓

 

Recentemente, estou estudando como configurar a autenticação OAuth2 para o repositório InterSystems FHIR. E descobri que os seguintes artigos são muito bons e fáceis de seguir.😁

SMART on FHIR EHR Launch com IRIS for Health

Construindo um Repositório FHIR + Configuração de Servidor de Autorização OAuth2/Servidor de Recursos no IRIS for Health Parte 2

 

Para mim, como um usuário que não possui muito conhecimento sobre OAuth2.0, acho bastante difícil entender como configurar todo o ambiente OAuth2.0 antes de saber como ele se parece (o que é? quais são os parâmetros que preciso? qual é o resultado esperado?) de um ponto de vista puramente de usuário. 🤔 Aqui, tento inverter um pouco a sequência: vamos tentar falar sobre OAuth2.0 primeiro pelo lado do cliente. E, aqui, usaremos o Postman como cliente.😁

Se você quiser ter um ambiente de teste para OAuth, pode tentar os seguintes dockers:

workshop-iris-oauth2 ou o docker neste artigo Construindo um Repositório FHIR + Configuração de Servidor de Autorização OAuth2/Servidor de Recursos no IRIS for Health Parte 1

Neste artigo, configurei um repositório InterSystems FHIR com suporte a HTTPS em minha máquina local. (Baseado na minha observação, corrija-me se eu estiver errado, para fazer o OAuth da InterSystems funcionar, o servidor de recursos deve suportar HTTPS😑😐)

 

---

Então, vamos começar por algo simples. 😀

Caso 1: Autenticação Básica 

 As informações que precisamos são:

 

Embora testar no Postman seja simples, a aparência é a seguinte:

Em geral, a autenticação básica é simples, porque tudo o que você precisa é da URL dos recursos que deseja obter e fornecer a credencial correspondente. 1 passo e você obtém os dados que deseja.😁✌

 

---

Caso 2: Autenticação OAuth 

O conceito é um pouco diferente da autenticação básica. Pelo meu entendimento, a diferença chave é o conceito de sessão e token. Talvez, antes de mergulharmos de fato no OAuth2.0, vamos falar sobre algo com o qual estamos familiarizados.

Considere o seguinte cenário: você deseja visitar um Museu de Arte para um evento especial chamado "O Momento Milagroso". Como este evento é muito popular, o Museu decidiu configurar um controle de fluxo, dividindo o horário de abertura em 8 sessões, cada sessão com duração de 1 hora, e o visitante deve reservar sua própria sessão na Bilheteria antes da visita. Em outras palavras, o visitante deve apresentar um bilhete válido (token) no horário correto (sessão) ao Museu de Arte para o evento "O Momento Milagroso".

 

A partir do cenário acima, podemos resumir o seguinte: do ponto de vista de um cliente OAuth2.0, para acessar os recursos que queremos, precisamos:

Passo 1: obter um token do Servidor de Autenticação (Comprar um bilhete na Bilheteria)

Passo 2: apresentar o token ao Servidor de Recursos (Apresentar o bilhete no Museu de Arte)

Para obter o token, você precisa informar ao Servidor de Autenticação:

1. Quem é você? (uma das formas mais simples é fornecer o client_id e o client_secret; claro que existem outras formas, mas quero manter a simplicidade aqui😁)

2. Qual é o Servidor de Recursos que você deseja acessar? (Qual museu? Qual local?), você pode fornecer isso no parâmetro audience.

3. Qual é o escopo (scope) do seu acesso? (Qual programa? Qual evento?), você pode fornecer isso no Scope, e este escopo deve ser definido entre o Servidor de Autenticação e o Servidor de Recursos.

 

Então... agora ... é hora de agir como um cliente

com as informações abaixo, e obter o token pelo Postman:

Após a conclusão da autenticação, clique em "use token"

 

Uhuuu!! agora temos um token válido aqui,😁😂 e ele expirará dentro de uma hora 😶🤐

 

Agora use o token para obter o recurso que desejamos

 

Agora tente obter o Recurso Patient (Paciente)

 

 

 

Uhuuu!! parece bom.😁

Obrigado pela leitura.