Pular para conteúdo

Modelo de Referência para Segurança (Autenticação e Autorização JWT em aplicativos da Web)

A Internet influenciou muito o desenvolvimento de vários métodos de identificação, autenticação e autorização. No entanto, também facilitou o surgimento de identidades falsas e atividades anônimas. Portanto descreveremos a seguir sobre as características do processo de controle de acesso e os diferentes processos envolvidos na obtenção de acesso.

O acesso não autorizado é um risco significativo que representa uma séria ameaça ao mundo digital. Isso pode levar a consequências devastadoras, como violações de dados, ransomware (tipo de malware que sequestra o computador da vítima) e vazamento de senhas. Em muitos casos, estas violações de segurança ocorrem devido a mecanismos de controlo de acesso fracos e à utilização inadequada de tecnologias modernas para proteger os sistemas digitais.

01. Conceitos básicos

01.1. Identificação

Identificação refere-se ao processo de conectar uma pessoa específica com uma identidade particular entre muitas. Isto é, seguido por autenticação e autorização. Neste contexto, surgem as seguintes questões: 'A pessoa é quem afirma ser?', 'Esta pessoa já esteve aqui antes?' e 'Esse indivíduo deve ter acesso ao nosso sistema?' As definições mais recentes para essas questões são apresentadas em diversas publicações de pesquisa, como é apresentada em uma abordagem usando cartões inteligentes e certificados X.509 para fornecer identificação do usuário e garantir a privacidade e integridade dos dados.

01.2. Autenticação

A autenticação determina se um usuário ou processo é a pessoa ou entidade que afirma ser. Garante que a entidade comunicante é genuína. O usuário deve fornecer as credenciais necessárias para acessar o serviço web durante o processo de autenticação. A autenticação biométrica ganhou mais atenção, especialmente depois que o Google e outros provedores de identidade introduziram a tecnologia de chave de acesso. Porém, ao mesmo tempo, mais ataques estão sendo implementados utilizando biometria, utilizando técnicas de Machine Learning.

Alguns dos métodos de autenticação, tradicionalmente, podem ser classificados da seguinte forma - Algo que sabemos (PIN, senhas). - Algo que temos (smart cards, certificados digitais, etc.). - Algo que você é (biométrico, impressões digitais, rosto, etc.).

A importância da autenticação reside no fato de validar usuários ou processos que reúnam as condições para obter acesso a recursos em dados sensíveis. Este parágrafo discute os benefícios da autenticação na proteção de dados e na limitação do acesso. A autenticação de múltiplos fatores é recomendada para aumentar a segurança, como combinar senhas com dados biométricos ou cartões inteligentes. Uma nova forma de autenticação que está ganhando popularidade é a autenticação por cookie, que usa um cookie HTTP para identificar um usuário em um serviço web. Isso é conveniente para os usuários, pois eles não precisam se lembrar dos dados de login sempre que visitam o site. No entanto, se os cookies não forem criptografados corretamente, podem ser roubados e representar riscos de segurança. O uso de SSL é recomendado para mitigar esse risco.

01.3. Autorização

Autorização é uma técnica de segurança para determinar os privilégios ou adequação de um usuário para executar tarefas específicas em um sistema. A autorização é a última cadeia após a identificação e autenticação, que completa o processo de concessão de acesso. A autorização também desempenha uma função no nível de acesso do usuário ou processo, ou a autorização exibe tantos recursos de serviço da web quanto o usuário tem permissão para acessar, ou o nível de acesso que o usuário ou processo possui neste caso.

A importância da autorização reside no facto de serem impostas ao utilizador limitações de usabilidade, que têm os seguintes efeitos:

  • Garante que os usuários não possam acessar uma conta que não seja deles.
  • Impede que visitantes e funcionários acessem áreas seguras.
  • Garante que todos os recursos não estejam disponíveis para contas gratuitas.
  • Garante que as contas internas tenham acesso apenas às informações de que necessitam.

A autorização trata de um conjunto mais detalhado de restrições de acesso a vários recursos do sistema, enquanto o resultado do processo de autenticação é uma decisão binária, verdadeira para concessão e falsa para rejeição de acesso.

01.3.1. Estratégias de Autorização**

  • RBAC (Role-Based Access Control): é uma estratégia de autorização que está diretamente relacionada à função, mas não ao usuário, onde a função é uma coleção de permissões que são atribuídas à função por um tempo especificado ou não especificado e a função é atribuído a um grupo de pessoas.
  • ReBAC (Relationship-Based Access Control): um tipo de código interessante que tenta responder à pergunta “Este usuário tem relacionamento suficiente com este objeto ou ação para poder acessá-lo?”, onde o usuário pode fazer parte de um grupo de usuários com gerenciamento de recursos próprio. Além disso, alguns links podem ser priorizados para serem preenchidos para que o usuário tenha acesso.
  • ABAC (Attribute-Based Access Control): é a estratégia mais simples, é atribuída a apenas um usuário e é verificado se o usuário em questão possui permissão para acessar aquele recurso. Além disso, o gerenciamento é mais definido para cada usuário onde os privilégios devem ser adicionados ou removidos.

01.3.2. Tipos de autorização

Basic Authentication é uma das autorizações mais antigas usadas em plataformas web antigas. É conhecida como um dos primeiros tipos de autorização ao nível da comunicação das plataformas web com o utilizador através da web. Seu uso expõe uma vulnerabilidade, pois contém nome de usuário e senha codificados com o protocolo base64.

O Protocolo de Autorização utilizado no cabeçalho da solicitação feita ao servidor como:

Authorization: Basic dXNlcjpwYXNzd29yZA==

Onde a parte após Basic é o usuário e a senha separados por dois pontos (:), ou seja, usuário:senha. Vamos apresentar o caso em que não há SSL ou o certificado X.509 da aplicação expira. Depois temos um caso que permite capturar todo o tráfego web com ferramentas como o wireshark, onde um simples filtro pode capturar o tráfego web. Até a conversão de Base64 para texto simples é realizada automaticamente, sem nenhum conhecimento mais profundo.

Authorization: Basic user:password

O procedimento de autorização na comunicação HTTP não é seguro, pois está em texto simples e pode ser lido por terceiros. Não é recomendado para uso em aplicações com dados confidenciais, mas se usado em uma conexão segura, é simples, pois exige que o usuário forneça um nome de usuário e uma senha para identificação.

Token Authentication é um método de autenticação mais recente e mais seguro para comunicação HTTP e HTTPS. Ele usa tokens de segurança, especificamente JSON Web Tokens (JWT), em vez de transmitir o usuário e a senha a cada solicitação. Após a autenticação bem-sucedida utilizando nome de usuário e senha, uma chave criptografada é gerada e validada pelo banco de dados da plataforma. A plataforma então gera um token JWT, que pode ser usado para solicitações subsequentes. Este processo aumenta a segurança, eliminando a necessidade de transmitir informações confidenciais a cada solicitação, melhorando a experiência do usuário e ao mesmo tempo protegendo dados confidenciais. Exemplo:

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Para fins profissionais os tokens devem conter data de validade.

01.4. Protocolos de Autorização

O objetivo de um protocolo de autenticação é verificar a identidade de um usuário ou sistema de software que está acessando uma plataforma. Isto é realizado pela parte receptora, tal como um servidor, confirmando a identidade da parte que se conecta. A autenticação de rede é um mecanismo de segurança amplamente utilizado em sistemas de computador, e vários métodos de autenticação são empregados para esse fim. Abaixo discutiremos vários protocolos de autenticação comumente usados:

01.4.1. Single Sign-On (SSO)

é um método de autenticação que permite aos usuários acessar com segurança vários aplicativos e sites usando um único conjunto de credenciais. Este método baseia-se numa relação de confiança estabelecida entre o fornecedor de serviços (uma aplicação) e um fornecedor de identidade.

Além disso, a relação de confiança entre o fornecedor de identidade e o fornecedor de serviços é estabelecida através da troca de um certificado. O certificado serve como um sinal de que as informações de identidade enviadas do provedor de identidade para o provedor de serviços são de uma fonte confiável. Nos processos de Single Sign-On (SSO), essas informações de identidade são apresentadas na forma de tokens que carregam detalhes de identificação do usuário, como endereço de e-mail ou nome de usuário.

01.4.2. A estrutura Security Assertion Markup Language (SAML)

é um método de autenticação amplamente utilizado que aproveita a Extensible Markup Language (XML) para a troca de dados de autenticação entre o usuário e o provedor de serviços que gerencia o processo de autorização. SAML funciona em conjunto com um provedor de identidade para autenticar usuários com segurança.

SAML simplifica o processo de autenticação e aumenta a segurança ao validar os certificados dos usuários para determinar se eles estão autorizados a usar um serviço web. Ao implementar uma solução Single Sign-On (SSO), o processo de autenticação é simplificado e a segurança é melhorada

01.4.3. OAuth 2.0

OAuth 2.0 ⧉ estrutura de autorização é um protocolo que permite a um usuário conceder a um site ou aplicativo de terceiros acesso aos recursos protegidos do usuário, sem necessariamente revelar suas credenciais de longo prazo ou mesmo sua identidade.

OAuth introduz uma camada de autorização e separa a função do cliente da do proprietário do recurso . No OAuth, o cliente solicita acesso a recursos controlados pelo proprietário do recurso e hospedados pelo servidor de recursos e recebe um conjunto de credenciais diferente daquele do proprietário do recurso. Em vez de usar as credenciais do proprietário do recurso para acessar recursos protegidos, o cliente obtém um token de acesso – uma string que denota um escopo específico, tempo de vida e outros atributos de acesso. Os tokens de acesso são emitidos para clientes terceiros por um servidor de autorização com a aprovação do proprietário do recurso. Em seguida, o cliente utiliza o token de acesso para acessar os recursos protegidos hospedados pelo servidor de recursos.

Auth0 gera tokens de acesso para cenários de autorização de API, em Formato de token web JSON (JWT) ⧉. As permissões representadas pelo token de acesso, em termos OAuth, são conhecidas como escopos ⧉. Quando um aplicativo se autentica com Auth0, ele especifica os escopos desejados. Se esses escopos forem autorizados pelo usuário, o token de acesso representará esses escopos autorizados.

Funções:

  • Resource Owner : entidade que pode conceder acesso a um recurso protegido. Normalmente, este é o usuário final.
  • Resource Server : Servidor que hospeda os recursos protegidos. Esta é a API que você deseja acessar.
  • Authorization Server : Aplicativo que solicita acesso a um recurso protegido em nome do Resource Owner.
  • Servidor de Autorização : Servidor que autentica o Resource Owner e emite tokens de acesso após obter a autorização adequada. Neste caso, Auth0.

Endpoints: - '/authorizeendpoint é usado para interagir com o proprietário do recurso e obter autorização para acessar o recurso protegido. -/oauth/token`endpoint é usado pelo aplicativo para obter um token de acesso ou um token de atualização .

01.4.4. OpenID Connect

OpenID Connect ⧉ é um protocolo de autenticação interoperável baseado na estrutura de especificações OAuth 2.0 (IETF RFC 6749 e 6750). Ele simplifica a maneira de verificar a identidade dos usuários com base na autenticação realizada por um Authorization Server e de obter informações de perfil do usuário de maneira interoperável e semelhante a REST.

O OpenID Connect permite que desenvolvedores de aplicativos e sites iniciem fluxos de login e recebam afirmações verificáveis ​​sobre usuários em clientes baseados na Web, móveis e JavaScript. E o conjunto de especificações é extensível para suportar uma variedade de recursos opcionais, como criptografia de dados de identidade, descoberta de provedores OpenID e logout de sessão.

Para os desenvolvedores, ele fornece uma resposta segura e verificável à pergunta “Qual é a identidade da pessoa que usa atualmente o navegador ou aplicativo móvel que está conectado?” O melhor de tudo é que elimina a responsabilidade de definir, armazenar e gerenciar senhas, que é frequentemente associada a violações de dados baseadas em credenciais.

O OpenID Connect permite um ecossistema de identidade da Internet por meio de fácil integração e suporte, configuração que preserva segurança e privacidade, interoperabilidade, amplo suporte de clientes e dispositivos e permite que qualquer entidade seja um provedor OpenID (OP).

O protocolo OpenID Connect, em resumo, segue estas etapas:

  1. O usuário final navega para um site ou aplicativo da web por meio de um navegador.
  2. O usuário final clica em entrar e digita seu nome de usuário e senha.
  3. O RP (Cliente) envia uma solicitação ao OpenID Provider (OP).
  4. O OP autentica o usuário e obtém autorização.
  5. O OP responde com um Identity Token e geralmente com um Access Token .
  6. O RP pode enviar uma solicitação com o token de acesso ao dispositivo do usuário.
  7. O UserInfo Endpoint retorna declarações sobre o usuário final.

Access Token:

O Access Token descrito na etapa 5, definido na especificação como "ID Token ⧉": é um token de segurança que contém declarações sobre a autenticação de um usuário final por um servidor de autorização ao usar um cliente e, potencialmente, outras declarações solicitadas. O ID Token é representado como um JSON Web Token (JWT) ⧉

Este token possui as seguintes declarações são usadas no token de ID para todos os fluxos OAuth 2.0 usados ​​pelo OpenID Connect (podendo ser vistos ao decorificar o access token recebido do OP em ferramentas como o site JWT.IO ⧉): - iss: (OBRIGATÓRIO) Identificador da URL do Emissor (ex: "iss": "https://server.example.com ⧉"). - sub: (OBRIGATÓRIO) Identificador do Usuário Final, que se destina a ser consumido pelo Cliente, (ex: "sub": "AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4"). - aud: (OBRIGATÓRIO) Público(s) ao qual este token de ID se destina (ex: "aud": "account") - exp: (OBRIGATÓRIO) Tempo de expiração em ou após o qual o ID Token não deve ser mais aceito (ex: "exp": 1311281970, seu valor é um número JSON [RFC8259] que representa o número de segundos de 1970-01-01T00:00:00Z (Consulte RFC 3339 [RFC3339] para obter detalhes)) - iat: (OBRIGATÓRIO) Hora em que o JWT foi emitido. Seu valor é um número JSON que representa o número de segundos de 1970-01-01T00:00:00Z conforme medido em UTC até a data/hora (ex: "iat": 1311280970). - auth time: Hora em que ocorreu a autenticação do usuário final. Seu valor é um número JSON que representa o número de segundos de 1970-01-01T00:00:00Z conforme medido em UTC até a data/hora (ex: "auth_time": 1311280969). - acr: identifica a Classe de Contexto de Autenticação que a autenticação executada satisfez. O valor "0" indica que a autenticação do usuário final não atendeu aos requisitos da ISO/IEC 29115 (ex: "acr": "1") - azp: Cliente OAuth2 ao qual o ID Token foi emitido. (ex: azp": "app-frontend")

A documentação oficial prevê 3 tipois de fluxos de autenticação: - Autenticação utilizando o Fluxo de Código de Autorização. - Autenticação usando o fluxo implícito. - Autenticação utilizando o Fluxo Híbrido.

Authorization Code Flow Steps (Autenticação utilizando o Fluxo de Código de Autorização):

O Fluxo de Código de Autorização retorna um Código de Autorização ao Cliente, que pode então trocá-lo por um Token de ID e um Token de Acesso diretamente. Isso oferece o benefício de não expor nenhum token ao Agente do Usuário e possivelmente a outros aplicativos maliciosos com acesso ao Agente do Usuário. Seguem as etapas:

  1. O cliente prepara uma solicitação de autenticação contendo os parâmetros de solicitação desejados.
  2. O cliente envia a solicitação ao Authorization Server.
  3. Servidor de autorização autentica o usuário final.
  4. O Authorization Server obtém o consentimento/autorização do usuário final.
  5. O Servidor de Autorização envia o Usuário Final de volta ao Cliente com um Código de Autorização.
REQUEST:
GET server.example.com/authorize?
response_type=code
&scope=openid%20profile%20email
&client_id=s6BhdRkqt3
&state=af0ifjsldkj
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

RESPONSE (200 OK):
{
"code"="SplxlOBeZQQYbYS6WxSbIA",
"state"="af0ifjsldkj"
}

RESPONSE (400 NOK):
{
"error"=invalid_request,
"error_description"=Unsupported%20response_type%20value,
"state"=af0ifjsldkj
}
  1. O cliente solicita uma resposta usando o Código de Autorização no Token Endpoint.
REQUEST:
POST server.example.com/token
header:
- Content-Type: application/x-www-form-urlencoded
- Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
params:
grant_type=authorization_code&
code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

RESPONSE (200 OK):
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"refresh_token": "8xLOxBtZp8",
"expires_in": 3600,
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc 
yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}

RESPONSE (400 NOK):
{
"error": "invalid_request"
}
  1. O cliente recebe uma resposta que contém um token de ID e um token de acesso no corpo da resposta.
  2. O cliente valida o token de ID e recupera o identificador de assunto do usuário final.

Recomendações: - A comunicação com o endpoint de autorização DEVE utilizar TLS. - "scope=openid": As solicitações do OpenID Connect DEVEM conter o valor do escopo openid ("scope" : "openid"). Se o valor do escopo openid não estiver presente, o comportamento será totalmente inespecífico. - "response_type=code": Valor do tipo de resposta do OAuth 2.0 que determina o fluxo de processamento de autorização a ser usado deve ser "code". - "client_id": Identificador do cliente OAuth 2.0 válido no Authorization Server. "client_id". - "redirect_uri", URI de redirecionamento para o qual a resposta será enviada. Este URI DEVE corresponder exatamente a um dos valores do URI de Redirecionamento para o Cliente pré-registrado no Provedor OpenID. - "state": É recomentado usar o parametro "state", valor opaco usado para manter o estado entre a solicitação e o retorno de chamada. - "grant_type": para solicitar um token deve ser usado o metoto de autenticação "authorization_code", contudo se o cliente for um cliente conficencial, ele deve autenticar-se usando o método "client_id"

Validação do token:

  • O identificador do emissor para o provedor OpenID (que normalmente é obtido durante a descoberta) DEVE corresponder exatamente ao valor da "Claim iss" (emissor);
  • O Cliente deve validar se a "Claim aud" (audience) contém seu valor "client_id" registrado no Emissor;
  • A hora atual DEVE ser anterior à hora representada pela "Claim exp".

Authentication using the Implicit Flow (Autenticação usando o fluxo implícito)

O Token de Acesso e o Token de ID são devolvidos diretamente ao Cliente, o que pode expô-los ao Usuário Final e aos aplicativos que têm acesso ao Agente do Usuário do Usuário Final. Seguem as etapas:

  1. O cliente prepara uma solicitação de autenticação contendo os parâmetros de solicitação desejados.
  2. O cliente envia a solicitação ao Authorization Server.
REQUEST:
GET server.example.com/authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj HTTP/1.1

RESPONSE (200 OK):
access_token=SlAV32hkKG
&token_type=bearer
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&expires_in=3600
&state=af0ifjsldkj
  1. Servidor de autorização autentica o usuário final.
  2. O Authorization Server obtém o consentimento/autorização do usuário final.
  3. O Servidor de Autorização envia o Usuário Final de volta ao Cliente com um Token de ID e, se solicitado, um Token de Acesso.
  4. O cliente valida o token de ID e recupera o identificador de assunto do usuário final.

Parâmetros de Solicitação de Autenticação:

  • "response_type": Valor do tipo de resposta do OAuth 2.0 que determina o fluxo de processamento de autorização a ser usado, Ao usar o Fluxo Implícito, esse valor é id_token token ou id_token;

  • "redirect_uri": RI de redirecionamento para o qual a resposta será enviada.

  • "nonce": Valor de string usado para associar uma sessão do Cliente a um token de ID e para mitigar ataques de repetição.

Hybrid Flow Steps (Etapas de fluxo híbrido)

  1. O cliente prepara uma solicitação de autenticação contendo os parâmetros de solicitação desejados.
  2. O cliente envia a solicitação ao Authorization Server.
  3. Servidor de autorização autentica o usuário final.
  4. O Authorization Server obtém o consentimento/autorização do usuário final.
  5. O Servidor de Autorização envia o Usuário Final de volta ao Cliente com um Código de Autorização e, dependendo do Tipo de Resposta, um ou mais parâmetros adicionais.

REQUEST:
GET server.example.com/authorize?
response_type=code%20id_token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile%20email
&nonce=n-0S6_WzA2Mj
&state=af0ifjsldkj HTTP/1.1

RESPONSE (200 OK):
code=SplxlOBeZQQYbYS6WxSbIA
&id_token=eyJ0 ... NiJ9.eyJ1c ... I6IjIifX0.DeWt4Qu ... ZXso
&state=af0ifjsldkj
6. O cliente solicita uma resposta usando o Código de Autorização no Token Endpoint. 7. O cliente recebe uma resposta que contém um token de ID e um token de acesso no corpo da resposta. 8. O cliente valida o token de ID e recupera o identificador de assunto do usuário final.

Parâmetros de Solicitação de Autenticação:

  • "response_type": Valor do tipo de resposta do OAuth 2.0 que determina o fluxo de processamento de autorização a ser usado, Ao usar o FHíbrido, esse valor é code id_token, code token ou code id_token token;

  • "nonce" Valor de string usado para associar uma sessão do Cliente a um token de ID e para mitigar ataques de repetição.

Iniciando login de terceiros

Em alguns casos, o fluxo de login é iniciado por um provedor OpenID ou outra parte, e não pela terceira parte confiável. Nesse caso, o iniciador redireciona para o RP em seu endpoint de iniciação de login, que solicita que o RP envie uma solicitação de autenticação para um OP especificado.

A parte que inicia a solicitação de login faz isso redirecionando para o endpoint de iniciação de login no RP, passando os seguintes parâmetros:

  • iss: (Obrigatório) Identificador do emissor do OP para o qual o RP deve enviar a solicitação de autenticação. Seu valor DEVE ser uma URL (usando HTTPS em ambiente produtivo)

  • login_hint (Optional) Dica ao servidor de autorização sobre o usuário final a ser autenticado. O significado deste parâmetro com valor de string fica a critério do OP. Em casos de uso comuns, o valor conterá um endereço de e-mail, número de telefone ou nome de usuário coletado pelo RP antes de solicitar autenticação no OP.

  • target_link_uri (Opcional) URL para a qual o RP é solicitado a redirecionar após a autenticação. Os RPs DEVEM verificar o valor de target_link_uri para evitar serem usados ​​como um redirecionador aberto para sites externos.

Os parâmetros podem ser passados ​​como parâmetros de consulta usando o método HTTP GET ou como valores de formulário HTML que são enviados automaticamente no Agente do Usuário e, portanto, transmitidos por meio do método HTTP POST .

Outros parâmetros PODEM ser enviados, se definidos pelas extensões. Quaisquer parâmetros utilizados que não sejam compreendidos DEVEM ser ignorados pelo Cliente.

Os clientes DEVEM empregar frame busting e outras técnicas para evitar que os usuários finais façam login em sites de terceiros sem o seu conhecimento por meio de ataques como Clickjacking.

Recomendações de configuração do ambiente

1) Utilizar canais protegido como TLS em ambiente produtivo (16.3.Token Manufacture/Modification; 16.10. Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture); 16.11.Token Substitution; 16.21. Need for Encrypted Requests).

2) Utilizar o fluxo Authentication using the Authorization Code Flow, pois as aplicações (Client-side) tem seu javascript baixado para o cliente o que irá expor o "client-secret" (16.4.Access Token Disclosure; 16.11. Token Substitution; 16.16.Implicit Flow Threats).

3) Utilizar a definição de CORs em ambiente produtivo no serviços expostos na internet (Nesta arquitetura proposta API Gateway), assim como restringir "Web origins" no Keycloak;

4) Identificar o usuário logado nos enpoints pelo token. Não utilizar identificação por ID (numérico) para evitar visulização/modificação de dados indevidos (16.8.Access Token Redirect).

5) Em nenhuma hipotese passar identificadores de usuários utilizando o metodo HTTP GET (16.8.Access Token Redirect).

6) Em caso de requisições a dados sensíveis (exceto identificador de usuário) utilizando o método http "GET" dar preferência ao uso de identificadores UUID a identificadores numéricos (17.3. Correlation).

7) Criptografar o token JWT com chaves cifradas utilizando as configurações do Keycloak (16.2.Server Masquerading; 16.10.Eavesdropping or Leaking Authorization Codes (Secondary Authenticator Capture); 16.21. Need for Encrypted Requests)

8) A vida útil do token de acesso deve de curta duração.

9) Utilizar "AccessToken" de curta duração em ambiente produtivo (o tempo de vida padrão do Keycloak é de 5 minutos), prorrogável por meio de uma solicitação ao endpoint Token Endpoint usar um "Refresh Token" (que por padrão no Keycloak tem um tempo de vida de 30 minutos). Para exemplificar esse fluxo antes de cada requisição com usuário logado a aplicação frontend deve validar expiração do "AccessToken" para autorizar a solicitação, caso o token esteja expirado, deve validar a expiração do "Refresh Token" para solicitar uma renovação do "AccessToken" e revogar o "Refresh Token" usado na última requisição (No keycloak é regomendável usar o endpoint de Logout para essa finalidade). Entretanto caso o "Refresh Token" também esteja expirado, o recomendável é limpar os registros do usuário do navegador, executar o endpoint de Logout e redirecionar o usuário para a página de autenticação. (16.18.Lifetimes of Access Tokens and Refresh Tokens) Limpar o token armazenado no navegador assim como encerrar a sessão do usuário.

10) Utilizadas maneiras seguras de armazenamento dos dados de autorização do usuário na aplicação frontend atravez de APIs frontend que implementem a especificação OpenID Connect(OIDC) (16.4.Access Token Disclosure).

Recomendações já asseguradas pelo uso do Keycloak

1) O servidor registra o estado de uso do token e verificar o status de cada solicitação.

2) Implementar ou utilizar um "Authorization Server" que implementa a especificação OpenId para se proteger de uma série de ataques. (16.1.Request Disclosure; 16.3.Token Manufacture/Modification; 16.5.Server Response Disclosure; 16.6.Server Response Repudiation; 16.7.Request Repudiation; 16.9.Token Reuse; 16.11.Token Substitution; 16.12.Timing Attack; 16.14.Signing and Encryption Order; 16.15.Issuer Identifier; 16.17.TLS Requirements; 16.19. Symmetric Key Entropy; 16.20.Need for Signed Requests; 16.22.HTTP 307 Redirects; 17.1.Personally Identifiable Information; 17.2.Data Access Monitoring; 17.3.Correlation).

01.3. API Gateway

No ambiente de microsserviços, O API Gateway ⧉ atua como um intermediário entre o

cliente e os microsserviços (diminuindo a exposição dos microsserviços). Fornece um ambiente de rede privada que permite a troca de dados privados, ou seja, os clientes não se comunicam diretamente com os

serviços, mas apenas com um único gateway, que por sua vez se comunica com o serviço

requisitado. Ele pode ser uma entrada que realiza o filtro das solicitações do cliente e

faz o devido encaminhamento para o microsserviço. Checa as credenciais do usuário,

para conferir se ele possui a devida autorização.

02. Versões/Releases aplicáveis:

02.1. Open Source Single Sign-On (SSO) Solutions

Gluu

Gluu ⧉ é uma plataforma SSO de código aberto com uma grande variedade de recursos para autenticação e gerenciamento de acesso. Seu principal objetivo é manter a plataforma segura. É também uma das soluções SSO de código aberto líderes do mercado. Seu logon único (SSO) para todos os aplicativos melhora muito a experiência do usuário além dos limites dos protocolos mencionados acima.

Ele fornece um servidor de autorização para autenticação web e API, bem como oferece um diretório separado para armazenar dados de identidade. Além disso, para identidades de entrada, autenticação de dois fatores, bem como integração de diretórios, fornece um diretório para identificação de armazenamento de dados, middleware de autenticação.

Características do Gluu:

  • SSO para aplicativos web e móveis
  • SSO de entrada
  • Login social
  • Autenticação forte
  • Gerenciamento de acesso
  • Gerenciamento de identidade
  • Integração de diretório
  • Apoio comunitário e base de conhecimento

Preço: O preço normal do Gluu é de US$ 5/mês/usuário para o pacote básico. O preço do Gluu é de US$ 25/mês/usuário para o pacote premium.

Na Sennovate ⧉ , oferecemos o servidor Gluu com o melhor preço do setor. Para 1.000 funcionários, o custo médio anual de um servidor Gluu será de US$ 240.000. O ROI anual para Gluu empresarial será de US$ 2.666.250. Quer calcular o preço de acordo com suas necessidades e exigências? Você pode clicar aqui ⧉ para calcular!

Keycloak

Keycloak ⧉ é uma ferramenta de gerenciamento de identidade e acesso (IAM) de código aberto com licença Apache License 2.0. Além disso, permite SSO em serviços e aplicativos da web. KeyCloak é um software de código aberto disponível no Github. KeyCloak é escrito principalmente em Java com breves informações de outras linguagens que incluem JavaScript e HTML. Ele ajuda você a configurar um provedor de logon único seguro. Vários protocolos, como SAML 2.0 e OpenID Connect, são suportados pelo keycloak. As credenciais do usuário também são armazenadas pelo keycloak localmente ou por meio de um back-end LDAP ou Kerberos. Além disso, também é apoiado pelo projeto Red Hat SSO.

Recursos: - SSO - Login social - Gestão centralizada - Corretagem de identidade - Temas

Preço: Keycloak é a solução SSO completa e gratuita de código aberto.

IdentityServer

IdentityServer ⧉ também é uma solução de logon único de código aberto disponível no mercado. É baseado em OpenID Connect e OAuth 2 e é uma estrutura multiplataforma. Além disso, para vários aplicativos, este software de código aberto fornece recursos centrais de autenticação e autorização. Identidades federadas, múltiplos fluxos e autorização de API são suportados por isso. Além disso, o software IdentityServer permite que os usuários façam login com apenas um conjunto de credenciais em vários aplicativos. Além disso, o IdentityServer é escrito principalmente em C# e todo o seu código-fonte está disponível no Github junto com a documentação relativa à implantação e desenvolvimento.

Recursos: - Provedor baseado em reivindicações - Plataforma cruzada - Personalização da IU - Controle de acesso para API - Logon único/Sair

Preço: Assim como o Keycloak, o IdentityServer também é a solução SSO completa e gratuita de código aberto.

IBM Cloud Identity

Crie uma rede de usuário segura com Single Sign-On (SSO), autenticação multifator (MFA) e recursos de governança de identidade com a ajuda do IBM Cloud Identity ⧉ . Muitos conectores pré-construídos para aplicativos populares de terceiros, bem como modelos para ajudar a integrar aplicativos internos, estão incluídos nele.

Recursos: - SSO federado para aplicativos em nuvem - Plataforma de lançamento de funcionários - Catálogo de conectores on-line - Delegação de aplicativos

Preço: O IBM Cloud Identity oferece planos gratuitos e premium. O plano gratuito é limitado a cinco aplicativos conectados para usuários ilimitados.

Por outro lado, o plano pago do IBM Cloud Identity: - SSO ilimitado a partir de US$ 2,50/mês por usuário para aplicativos locais e na nuvem. - A autenticação multifator está disponível a partir de US$ 5/mês por funcionário. - O provisionamento começa em US$ 4/mês por funcionário.

Microsoft Azure Active Directory

O Microsoft Azure Active Directory ⧉ ajuda os usuários empresariais a se conectarem perfeitamente com seus aplicativos e dados. A plataforma apresenta integrações pré-construídas com milhares de ferramentas de software, mas foi projetada pensando em outros produtos da Microsoft. Vários recursos, como o provisionamento de usuários com segurança aprimorada com opções de acesso baseadas na localização, no dispositivo e no contexto do aplicativo, são fornecidos pelo diretório ativo do Microsoft Azure.

Recursos: - Limite de 500.000 objetos de diretório - SSO com 10 aplicativos por usuário - Gerenciamento e provisionamento de usuários/grupos - Colaboração B2B - Alteração de senha de autoatendimento para usuários da nuvem - Relatórios básicos de segurança e uso

Preço: O Microsoft Azure Active Directory oferece um plano gratuito com limite de SSO de 10 aplicativos por usuário.

Os planos premium incluem: - O plano Básico – Disponível por US$ 1/mês por usuário. - O plano Premium P1 – Disponível por US$ 6/mês por usuário. - O plano Premium P2 – Disponível por US$ 9/mês por usuário.

Referências: https://sennovate.com/best-open-source-single-sign-on-solutions/ ⧉

02.2. Serviços de autenticação e autorização de segurança (AAS)

Java

Spring Security ⧉, é uma estrutura que fornece autenticação , autorização e proteção contra ataques comuns . Com suporte de primeira classe para proteger aplicativos imperativos e reativos , é o padrão de fato para proteger aplicativos baseados em Spring.

Recursos: - Autenticação ⧉ - Autorização ⧉ - Proteção contra explorações ⧉ - Integrações ⧉

PHP

Laravel ⧉: - Inclui autenticação integrada e serviços de sessão que normalmente são acessados ​​através das fachadas Authe . SessionEsses recursos fornecem autenticação baseada em cookies para solicitações iniciadas em navegadores da web. Eles fornecem métodos que permitem verificar as credenciais de um usuário e autenticá-lo. Além disso, esses serviços armazenarão automaticamente os dados de autenticação adequados na sessão do usuário e emitirão o cookie de sessão do usuário. - Fornece dois pacotes opcionais para ajudá-lo no gerenciamento de tokens de API e na autenticação de solicitações feitas com tokens de API: Passport ⧉ e Sanctum ⧉ . Observe que essas bibliotecas e as bibliotecas de autenticação baseadas em cookies integradas do Laravel não são mutuamente exclusivas. Essas bibliotecas se concentram principalmente na autenticação de token de API, enquanto os serviços de autenticação integrados se concentram na autenticação de navegador baseada em cookies. Muitos aplicativos usarão os serviços de autenticação baseados em cookies integrados do Laravel e um dos pacotes de autenticação de API do Laravel..

Zend Framework 2 ⧉: - Zend\Authentication ⧉: está preocupado apenas com autenticação e não com autorização. A autenticação é vagamente definida como determinar se uma entidade realmente é o que pretende ser (ou seja, identificação), com base em algum conjunto de credenciais. Autorização, o processo de decidir se permite que uma entidade acesse ou execute operações em outras entidades está fora do escopo do Zend\Authentication. - Zend\Permissions\Acl ⧉: fornece uma implementação de lista de controle de acesso ( ACL ) leve e flexível para gerenciamento de privilégios. Em geral, uma aplicação pode utilizar tais ACLs para controlar o acesso a certos objetos protegidos por outros objetos solicitantes.

NodeJs ⧉:

  • Passaporte.js ⧉ é um middleware para Node.js que facilita a implementação de autenticação e autorização

Python ⧉:

  • TokenAuth ⧉: A autenticação baseada em token pode ser considerada uma versão especializada da Autenticação Básica. A tag de cabeçalho de autorização conterá o token de autenticação como nome de usuário e nenhuma senha.

  • python-authorization ⧉: este módulo foi criado para fornecer um método de autorização simples para ser usado na autorização serviço a serviço.

02.3. Resource Server OAuth 2.0

Um servidor de recustos OAuth 2.0 delega seu gerenciamento de autoridade (autenticação e|ou autorização) à um serviço de autorização (por exemplo: Okta, Ping Identity, Keycloak e etc).

Java:

Neste estudo até o momento não foi encontrado recurso similar em outras linguagens.

02.3. API Gateway Solutions

Segue as principais tecnologias opensource para implementação de Api gateway segundo o site https://itechnolabs.ca/20-best-open-source-api-management-platforms/ ⧉

02.3.1. API Umbrella

API Umbrella é uma plataforma de código aberto para gerenciamento de APIs leve e flexível. Ele vem com recursos padrão, como limitação de taxa, opções plug-and-play de filtragem de IP, um portal de desenvolvedor de API de código aberto que inclui OAuth2, bem como política JSON para tokens da web. Ele também oferece balanceamento de carga e muito mais.

Porém, a principal característica da ferramenta de administração de APIs é a capacidade de produzir relatórios com uma estrutura refinada para entender as informações de uso que suas APIs recebem.

02.3.2. Gravitee.io

Gravitee.io é uma plataforma de código aberto para gerenciamento de APIs leve e flexível. Ele vem com recursos padrão, como limitação de taxa, opções plug-and-play de filtragem de IP, um portal de desenvolvedor de API de código aberto que inclui OAuth2, bem como política JSON para tokens da web. Ele também oferece balanceamento de carga e muito mais.

Porém, a principal característica da ferramenta de administração de APIs é a capacidade de produzir relatórios com uma estrutura refinada para entender as informações de uso que suas APIs recebem.

02.3.3. APIman.io

Criado através da Red Hat, APIman.io é uma das plataformas de gerenciamento de API mais populares que você deve considerar ao decidir sobre a pilha de tecnologia mais adequada para construir seu aplicativo.

A plataforma, acessível através do repositório GitHub, oferece inúmeras oportunidades para desenvolvedores que trabalham no desenvolvimento de backends. Isso inclui:

  • Tempo rápido para correr,
  • Governança baseada em políticas, com um mecanismo político destacável
  • Capacidade assíncrona
  • Opções para faturamento e análise aprimorados,
  • Acesso a uma API REST para gerenciar,
  • Taxas limitantes e muito mais.

02.3.4. WSO2 API Manager

O WSO2 API Manager pode ser descrito como um sistema de gerenciamento de API de ciclo de vida completo que pode ser executado de qualquer lugar e a qualquer hora. Ele permite que os desenvolvedores aproveitem as possibilidades de disseminação e implementação de API em nuvens privadas e locais.

Além disso, também oferece uma variedade de oportunidades diferentes. Um deles está entre eles: - Maior personalização - Facilitação de políticas que governam, - Possibilidade de desenvolvimento e prototipagem de APIs para APIs SOAP e RESTful. - Controle de acesso mais eficaz, facilidades para monetização, etc.

02.3.5. Kong Enterprise

Kong é uma ferramenta de código aberto de API de microsserviço amplamente usada que permite aos desenvolvedores gerenciar tudo de forma rápida, eficiente e segura. A Enterprise Edition do Kong vem repleta de funções e recursos, como:

  • Plug-ins de código aberto estão disponíveis,
  • Operação fácil com um clique,
  • Capacidade de infraestrutura de linguagem comum,
  • Visualização fantástica para monitorar,
  • Verificações de integridade de software agendadas regularmente,
  • Introspecção do OAuth2.0 e
  • Maior suporte baseado na comunidade.

02.3.6. Tyk.io

Escrito usando a linguagem de programação Go, Tyk.io também é um gateway de API de código aberto reconhecido que você deve ficar de olho.

Ele é acompanhado por um portal para desenvolvedores de API, documentação detalhada e um painel para análise de APIs, limites de taxas para APIs, autenticação e uma variedade de outras especificações que permitem que as organizações se concentrem em microsserviços e conteinerização.

No entanto, as versões comerciais estão disponíveis apenas ao custo de uma versão paga.

02.3.7. Fusio

Fusio está entre as ferramentas de gerenciamento de API de código aberto mais populares que permitem aos desenvolvedores desenvolver e manter APIs REST com base em vários tipos de dados. Possui vários recursos de gerenciamento de ciclo de vida, como um painel para back-end que permite controle de administração, documentos detalhados, validação JSON para solicitações recebidas e manipulação de escopo para garantir que as permissões do usuário sejam atendidas.

Além disso, a plataforma APIM gera automaticamente especificações OAI e RAML e cria um SDK cliente personalizado com base no esquema definido.

02.3.8. Apigility

O framework foi desenvolvido e é mantido pelo framework Zend. Apigility pode ser o novo framework de código aberto que você deve considerar para gerenciar APIs.

A plataforma permite que empresas bem estabelecidas de desenvolvimento de aplicativos móveis projetem e apresentem representações JSON de seu código. Ele também oferece várias opções de controle de versão, bem como facilidade de autenticação por meio de OAuth2 e documentação para aceitar um modelo de API. Projeto de API.

02.3.9. SwaggerHub

A escolha de mais de 40 empresas para gerenciar APIs SwaggerHub pode ser considerada uma das principais ferramentas de gerenciamento de API de código aberto em que se pode confiar.

A plataforma oferece uma ampla variedade de opções para designers e desenvolvedores que trabalham na área de desenvolvimento backend. Oferece a eles um editor robusto e fácil de usar que oferece mais eficiência e velocidade, mantendo a consistência do design.

Também oferece a possibilidade de alertas de erro inteligentes, preenchimento automático de sintaxe e disponibilidade de ferramentas de validação de vários estilos.

02.3.10. API Axle

Com o suporte da Exicon, o API Axle é outro serviço de proxy simples, leve e de código aberto que oferece às agências de desenvolvimento uma série de vantagens, incluindo:

  • Análise em tempo real
  • Autenticação robusta
  • Gravação de tráfego de API para rastrear estatísticas e relatórios,
  • Fácil de criar e gerenciar chaves de API, bem como
  • Suporte de design para API REST, bem como utilização em conjunto com bibliotecas Go, PHP e Node.js.

02.3.11. IBM Bluemix API

Esta ferramenta de gerenciamento de API permite que os desenvolvedores utilizem mais de 200 padrões de middleware e software para criar aplicativos que sejam portáteis e compatíveis para funcionar na nuvem híbrida. Ele também vem com uma gama de serviços pré-construídos, bem como um poderoso sistema para controlar o acesso à API, gerenciar o uso de múltiplas versões da API, garantir os limites de taxa e manter o monitoramento das métricas de desempenho e dados de cada API associada.

02.3.12. Repose

Repose é um sistema de middleware tranquilo de código aberto que desempenha um papel importante na estrutura em constante mudança do mercado de API. Ele oferece às organizações vários recursos de processamento de API, como validação de API de autenticação, limitação de taxa e registro HTTP de solicitações.

Este sistema de gerenciamento de API funciona com o objetivo de fornecer serviços downstream que possam ser confiáveis ​​para aceitar solicitações bem formadas e verificadas. Além disso, é adaptável e escalável, o que significa que os desenvolvedores podem implementá-lo rapidamente para atender às crescentes demandas e demandas.

02.3.13. SnapLogic Enterprise Integration Cloud

SnapLogic é uma excelente ferramenta de integração de plataforma como serviço (PaaS) que auxilia empresas na aquisição, sustentação e expansão de seus clientes. Os atributos que permitem isso são:

É multiponto rápido e rápido, além de oferecer a capacidade de adaptação aos requisitos de integração em tempo real e orientados a lote.

Ele é construído em uma estrutura flexível que funciona de forma semelhante aos servidores web, mas, além disso, permite aos usuários aproveitar a flexibilidade.

Também inclui soluções exclusivas de fluxo de dados que incentivam as empresas a integrar aplicativos conhecidos baseados em SaaS, como SugarCRM e Salesforce, em seus métodos existentes.

02.3.14. DreamFactory

A plataforma DreamFactory API Management é uma das ferramentas gratuitas e de código aberto mais eficazes que você pode imaginar ao planejar seu próximo empreendimento. As principais razões do seu sucesso são:

Ele permite que os desenvolvedores fujam da tediosa tarefa de codificar APIs para desenvolver aplicativos móveis. Ele permite que eles conectem qualquer banco de dados SQL/NoSQL, qualquer serviço HTTP/SOAP externo ou o armazenamento de arquivos no ambiente DreamFactory. Eles receberão uma API REST extensa e flexível, bem documentada e pronta para uso em questão de minutos.

A plataforma também possui uma extensa API REST para bancos de dados SQL, bem como a capacidade de acessar parâmetros de API para filtros avançados, junções de tabelas de chaves estrangeiras virtuais de paginação e muito mais.

Um recurso diferente da plataforma DreamFactory API Management é que ela converte instantaneamente a solicitação JSON em SOAP e reverte o processo.

Além disso, fornece serviços extremamente seguros por meio da facilidade de gerenciamento de usuários, autenticação SSO, integração CORS JSON Web Tokens SAML, bem como controle de acesso baseado em função em endpoints de API e OAuth e LDAP.

02.3.15. 3Scale

Para não ficar de fora, o 3Scale é uma inclusão notável nesta coleção de ferramentas para gerenciamento de APIs.

Como parte de propriedade da Red Hat, a ferramenta de gerenciamento de API permite que grandes e pequenas empresas gerenciem suas APIs facilmente com ferramentas como as seguintes:

Utiliza uma camada de nuvem distribuída em todo o mundo que centraliza o gerenciamento do programa API. Isso torna mais simples manter o controle sobre as análises, a acessibilidade dos fluxos de trabalho dos desenvolvedores, a monetização, etc.

Por estar hospedado em uma camada distribuída e hospedada em nuvem, é extremamente versátil e adaptável para uso.

  • Seu recurso de integração OpenShift da API 3Scale permite executar aplicativos extremamente rápidos de forma controlada e automatizada.
  • O sistema de gerenciamento de API de ciclo de vida completo permite que os desenvolvedores projetem, planejem aplicativos, implementem e monitorem, analisem, otimizem e desativem suas APIs a qualquer momento, para proporcionar uma experiência incrível.
  • Ele permite que você compartilhe dados de informações, serviços e outras informações da sua empresa através da Internet ou de aplicativos móveis rapidamente.
  • O mais importante é que o sistema de gerenciamento de API 3scale oferece a oportunidade de incorporar uma variedade de criptografia, bem como métodos de autenticação e autorização em seu ambiente de desenvolvimento. Isso permite que os serviços de software de desenvolvimento de back-end ofereçam uma experiência de aplicativo móvel altamente segura e adequada às necessidades de seus usuários.

02.3.16. Gloo Edge

Gloo Edge é um gateway de API nativo da nuvem de última geração que pode oferecer suporte a microsserviços e aplicativos legados e não tem servidor. Ele pode ser integrado ao seu ambiente existente e permite selecionar suas ferramentas preferidas para agendamento, persistência e segurança. O gateway de API gerencia a saída e a entrada, pois é o ponto de entrada para respostas e conexões de entrada. Gloo Edge também emprega os principais projetos de código aberto como GraphQL, gRPC, OpenTracing, NATS e muito mais, para oferecer recursos de alta qualidade.

02.3.17. Akana

Akana é outro excelente gateway de API aberto de código aberto. É uma plataforma de gerenciamento ponta a ponta de API. Ele permite desenvolver, proteger, criar monitoramento e publicar APIs nesta plataforma. Ele pode ser implementado tanto no local quanto na nuvem.

Os atributos mais notáveis ​​que fazem parte da plataforma API incluem:

  • Segurança contra ameaças
  • Plataforma líder de gerenciamento de API de código aberto,
  • Gerenciamento de microsserviços, bem como DevOps,
  • Auxilia no gerenciamento de tráfego.
  • Ele protege aplicativos detectando falhas no código ou no processo em tempo de execução,
  • Ele também fornece assistência de código aberto.

02.3.18. Mashery

A Mashery fornece ferramentas de gerenciamento de API de ciclo de vida completo líderes de mercado para empresas que usam práticas de implantação e desenvolvimento nativas da nuvem, como DevOps, microsserviços e contêineres. O extenso conjunto de recursos inclui criação e produção de API, bem como segurança e análise de seu programa de API, bem como da comunidade de desenvolvedores.

As características mais notáveis ​​do Mashery incluem: - Suporta a importação da especificação Swagger 2.0. - Fortaleza de API de integração. API Fortress para fornecer recursos adicionais de teste de API. - Controla a terminação SSL local e o gerenciamento de segredos.

02.3.19. Azure

O Microsoft Azure fornece gerenciamento completo de API para nuvem, local ou híbrida. É possível gerenciar o gerenciamento de APIs de maneira programática usando a API REST e também o SDK. Você também pode importar as linguagens de descrição de serviços da Web (WSDL) para o serviço SOAP e o Azure criará um front-end SOAP. Eles têm todos os recursos padrão que incluem a capacidade de monetizar. Também é possível melhorar a acessibilidade e usabilidade dos microsserviços que você utiliza em sua empresa utilizando os conceitos que fundamentam o gerenciamento de APIs.

02.3.20. KrakenD

Kraken é o principal API Gateway de código aberto. Sua principal função é construir uma API que funcione como um agregador de vários microsserviços em um endpoint, realizando o trabalho pesado para você: agregar, transformar, decodificar filtros, acelerar a autenticação e muito mais. Ele fornece um método declarativo para projetar os terminais. Ele é bem estruturado e possui camadas, o que o torna flexível o suficiente para permitir uma maior expansão de seus recursos por meio de middleware plug-and-play desenvolvido na comunidade de código aberto ou internamente.

As ferramentas de gerenciamento de API listadas acima são de código aberto e provavelmente constituirão uma pilha de tecnologia positiva. Para garantir que você escolha o mais adequado às suas necessidades de aplicativos e requisitos de negócios, apresentaremos algumas dicas para selecionar a ferramenta de gerenciamento de API certa a seguir.

02.3.Spring Cloud Gateway

Este projeto fornece bibliotecas para construir um API Gateway sobre Spring WebFlux ou Spring WebMVC. Spring Cloud Gateway tem como objetivo fornecer uma maneira simples, mas eficaz de rotear APIs e fornecer preocupações transversais a elas, como: segurança, monitoramento/métricas e resiliência.

Características - Recursos do Spring Cloud Gateway: - Construído em Spring Framework e Spring Boot - Capaz de combinar rotas em qualquer atributo de solicitação. - Predicados e filtros são específicos para rotas. - Integração do disjuntor. - Integração Spring Cloud DiscoveryClient - Fácil de escrever predicados e filtros - Limitação de taxa de solicitação - Reescrita de caminho

03. Pontos positivos

03.1 Pontos positivos de usar Single Sign-On (SSO) Solutions

O SSO tem um impacto positivo no processo de integração de um novo funcionário ou na implantação de um novo computador para um funcionário existente, reduzindo significativamente o tempo necessário para provisionar as diversas contas do usuário. O gerenciamento global de senhas é otimizado, pois os funcionários não são obrigados a atualizar cada aplicativo ou plataforma de software.

O SSO também vem com muitos recursos de segurança configuráveis. Um servidor de políticas gerencia credenciais, que podem ser configuradas para diferentes políticas e permissões de segurança. Relatórios, análises e registros de atividades estão disponíveis. Além disso, o acesso a todos os aplicativos e softwares acessados ​​por meio de SSO pode ser rescindido imediatamente se o usuário não for mais funcionário da empresa. Esse recurso simplifica muito o processo de desligamento.

Os benefícios adicionais da incorporação de uma solução de login único incluem: - Uma redução em erros de login e problemas/tickets de TI. - Os usuários finais não conseguem fazer login nas contas de outros usuários. - Novos aplicativos e softwares implantados de uma só vez, em vez de instalações individuais, o que acelera as taxas de adoção dos usuários. - Uma imagem clara de quais funcionários estão acessando vários aplicativos e softwares. - Sua equipe de serviços gerenciados de TI pode ser mais eficiente e terá mais tempo para se concentrar em outros trabalhos proativos para sua empresa. - Maior produtividade e segurança para funcionários remotos e forças de trabalho distribuídas

03.2 Pontos positivos de usar API Gateway Solutions

Usar um API Gateway em um sistema de software traz diversas vantagens que podem agilizar o processo de desenvolvimento, melhorar o desempenho e melhorar a segurança. Aqui estão as principais vantagens de usar um API Gateway:

  1. Melhor desempenho

O API Gateway pode armazenar respostas em cache, limitar a taxa de solicitações e otimizar a comunicação entre clientes e serviços de back-end, resultando em desempenho aprimorado e latência reduzida para usuários finais.

  1. Projeto de sistema simplificado

O API Gateway fornece um ponto de entrada único para todas as solicitações de API, facilitando o gerenciamento, o monitoramento e a manutenção de APIs em vários serviços de back-end. Isso simplifica o processo de desenvolvimento e implantação e reduz a complexidade do sistema geral.

  1. Segurança aprimorada

O API Gateway pode impor políticas de autenticação e autorização, ajudando a proteger os serviços de back-end contra acesso não autorizado ou abuso. Ao lidar com a segurança no nível do gateway, os desenvolvedores podem se concentrar na implementação da lógica comercial central em seus serviços sem se preocupar em implementar medidas de segurança em cada serviço individualmente.

  1. Escalabilidade aprimorada

O gateway de API pode distribuir solicitações recebidas entre várias instâncias de um microsserviço, permitindo que o sistema seja dimensionado com mais facilidade e lide com um número maior de solicitações.

  1. Melhor monitoramento e visibilidade

O gateway de API pode coletar métricas e outros dados sobre solicitações e respostas, fornecendo informações valiosas sobre o desempenho e o comportamento do sistema. Isto pode ajudar a identificar e diagnosticar problemas e melhorar a confiabilidade e resiliência geral do sistema.

  1. Integração simplificada do cliente

Ao fornecer uma interface consistente e unificada para que os clientes acessem vários serviços de back-end, o API Gateway simplifica o desenvolvimento do lado do cliente e reduz a necessidade de os clientes gerenciarem interações de serviços complexas.

  1. Transformação de protocolo e formato de dados

O API Gateway pode converter solicitações e respostas entre diferentes protocolos (por exemplo, HTTP para gRPC) ou formatos de dados (por exemplo, JSON para XML), permitindo maior flexibilidade na forma como clientes e serviços se comunicam e facilitando o processo de integração.

  1. Versionamento de API e compatibilidade com versões anteriores

O API Gateway pode gerenciar várias versões de uma API, permitindo que os desenvolvedores introduzam novos recursos ou façam alterações sem interromper os clientes existentes. Isso permite uma transição mais tranquila para os clientes e reduz o risco de interrupções de serviço.

  1. Tratamento de erros aprimorado

O API Gateway pode fornecer uma maneira consistente de lidar com erros e gerar respostas a erros, melhorando a experiência do usuário e facilitando o diagnóstico e a correção de problemas.

  1. Balanceamento de carga e tolerância a falhas

O API Gateway pode distribuir o tráfego de entrada uniformemente entre várias instâncias de um serviço de back-end, melhorando o desempenho e a tolerância a falhas. Isso ajuda a garantir que o sistema permaneça responsivo e disponível mesmo se serviços ou instâncias individuais apresentarem falhas ou ficarem sobrecarregados.

04. Pontos negativos

04.1 Pontos negativos de usar Single Sign-On (SSO) Solutions

Cada solução de TI tem vantagens e desvantagens, incluindo SSO. Aqui estão algumas desvantagens a serem consideradas ao consultar seu provedor de serviços de TI confiável:

  • Se o provedor de login único falhar, toda a sua empresa perderá o acesso aos aplicativos e softwares conectados.
  • Ainda existem alguns aplicativos que não suportam SSO. Isso faz com que os funcionários precisem de credenciais de login adicionais, o que anula a simplificação do ambiente com SSO.
  • Algumas empresas têm estações de trabalho compartilhadas. Por exemplo, um computador em uma sala de conferências ou um computador usado para arquivos extragrandes em uma empresa de desenvolvimento de produtos pode ser compartilhado por alguns (ou muitos) funcionários. O último usuário precisará ter certeza e sair sempre para evitar fornecer acesso acidental a todas as contas da empresa ao próximo usuário.
  • Empresas de vários setores, como bancário, exigem a geração de tokens de senha de uso único para acessar seus dados. Esses tipos de ferramentas de segurança não funcionam com SSO.
  • Se um provedor de login único for hackeado, todos os seus clientes ficarão vulneráveis. Quando combinado com a MFA, trata-se mais de uma interrupção dos negócios do que de uma grande violação de dados. A MFA adiciona uma camada adicional de segurança para que os dados não fiquem acessíveis.

03.2 Pontos negativos de usar API Gateway Solutions

Embora os gateways de API ofereçam vários benefícios, existem algumas desvantagens potenciais a serem consideradas ao decidir se deve usar um em seu sistema de software:

  1. Complexidade Adicional

A introdução de um API Gateway adiciona uma camada extra de complexidade à sua arquitetura. Os desenvolvedores precisam compreender e gerenciar esse componente adicional, o que pode exigir conhecimentos, habilidades e ferramentas adicionais.

  1. Ponto Único de Falha

Se não for configurado corretamente, o API Gateway poderá se tornar um ponto único de falha em seu sistema. Se o gateway sofrer uma interrupção ou problemas de desempenho, isso poderá afetar todo o sistema. É crucial garantir redundância, escalabilidade e tolerância a falhas adequadas ao implantar um API Gateway.

  1. Latência

O API Gateway adiciona um salto extra no caminho de solicitação-resposta, o que pode introduzir alguma latência, especialmente se o gateway for responsável por executar tarefas complexas, como transformação de solicitação/resposta ou autenticação. No entanto, o impacto geralmente é mínimo e pode ser mitigado por meio de otimizações de desempenho, armazenamento em cache e balanceamento de carga.

  1. Aprisionamento do fornecedor

Se você usar um serviço gerenciado de API Gateway fornecido por um provedor ou fornecedor de nuvem específico, poderá se tornar dependente de sua infraestrutura, preços e conjunto de recursos. Isso pode tornar mais difícil migrar suas APIs para um provedor ou plataforma diferente no futuro.

  1. Custo

A execução de um API Gateway, especialmente em cenários de alto tráfego, pode aumentar o custo geral da sua infraestrutura. Isso pode incluir o custo de hospedagem, licenciamento ou uso de serviços gerenciados de API Gateway de provedores de nuvem.

  1. Despesas gerais de manutenção

Um API Gateway requer monitoramento, manutenção e atualizações regulares para garantir sua segurança e confiabilidade. Isso pode aumentar a sobrecarga operacional para sua equipe de desenvolvimento, especialmente se você auto-hospedar e gerenciar seu próprio API Gateway.

  1. Complexidade de configuração

Os gateways de API geralmente vêm com uma ampla variedade de recursos e opções de configuração. Definir e gerenciar essas configurações pode ser complexo e demorado, especialmente ao lidar com vários ambientes ou implantações em larga escala.

Referências