Authlete - Visão Geral

O que é Authlete

Authlete provê Web APIs para você implementar OAuth 2.0 e OpenID Connect de maneira simples e rapida. Authlete pode ser utilizada como um serviço na nuvem ou como um produto rodando na sua infra estrutura. A documentação de nossa API está disponível online.

Porque Authlete

Uma empresa deve implementar OAuth 2.0 (e OpenID Connect) como pré-requisitos para fornecer APIs da Web de seu serviço. No entanto, requer muito tempo e esforço para implementar as especificações. Além disso, gerenciar dados relacionados às especificações é um incômodo. Esse obstáculo pode ser fatal para os provedores de serviços que competem no tempo de colocação no mercado e/ou não podem se dar ao luxo de implementar os pré-requisitos apenas com seus recursos de desenvolvedor.

É Authlete que resolve o problema. O Authlete oferece suporte a um grande número de especificações e dados relacionados ao host. Os usuários do Authlete podem começar a implementar APIs da Web de seus serviços sem se preocupar com os pré-requisitos.

Como a Authlete funciona

Authlete é um back-end como serviço e fornece APIs que ajudam você a implementar OAuth e OpenID Connect. Authlete trabalha por trás de seu serviço da web e não interage diretamente com seus usuários finais, clientes OAuth ou terceiros.

authlete's role in authorization

Authlete Features

A arquitetura “semi-hosted” tem os beneficios:

Open all tabs | Close all tabs

Authlete projetou e implementou todas as funções necessárias para implementar um servidor OAuth 2.0 e OpenID Connect como APIs da web. Além das funções de gerenciamento de metadados de aplicativos cliente e servidores de autorização, o Authlete também fornece funções para implementar terminais, como um terminal de autorização e um terminal de token.

Esta arquitetura exclusiva permite que os desenvolvedores usem qualquer linguagem de programação, incluindo Java, Ruby, PHP e C #. Nossas bibliotecas OSS e exemplos de implementações irão ajudá-lo a construir servidores OAuth / OIDC em alguns dias ou semanas .

Os endpoints OAuth, como o endpoint de autorização, serão colocados em seu ambiente, não no nosso. Portanto, você pode personalizar a interface do usuário e a experiência do usuário sem limite. Por exemplo, você pode separar a página de autenticação da página de autorização ou pode permitir que seus usuários finais escolham os escopos a serem concedidos.

O Authlete pode executar e gerenciar várias instâncias dos servidores OAuth 2.0 e OpenID Connect simultaneamente, que podem ser gerenciados por consoles.

É fácil configurar novas instâncias: um arquiteto, portanto, pode colocar vários servidores de autorização em um sistema sempre que apropriado, sem um grande custo de desenvolvimento. Por exemplo, um arquiteto pode ter servidores de autorização separados para aplicativos de smartphone dos serviços internos.

Você pode integrar o Authlete com qualquer solução IAM, solução de autenticação ou solução de gateway de API de sua escolha porque o Authlete se concentra apenas na função de autorização. Por exemplo, se você tiver sistemas de autenticação e IAM para o serviço existente, poderá minimizar o custo da introdução do OAuth e do OpenID Connect integrando o Authlete a esses sistemas.

O Authlete recebe assuntos de usuários finais de seu sistema e associa os assuntos a tokens de acesso e outros dados. Portanto, você não precisa compartilhar suas credenciais de usuário final conosco, o que é bastante exclusivo em comparação com outras soluções de autorização de API.

Authlete suporta muitas especificações. Aqui está a lista das especificações (algumas especificações estão disponíveis apenas para o plano ENTERPRISE).

Commercially Available

Available Soon

Funcionalidades únicas

Authlete oferece funcionalidades úteis para implantar, implementar e manter sistemas que suportam os protocolos OAuth e OpenID Connect.

Open all tabs | Close all tabs

As respostas de nossa APIs fornecem um código e uma mensagem no resultado.

Um exemplo de erro é "[A011308] The host of the redirect URI must be 'localhost' when the client's application type is 'native' and the scheme of the redirect URI is 'http'.", o que ajuda grandemente desenvolvedores a entenderem e resolver os problemas em curto espaço de tempo.

client_id_alias

Authlete permite que cada cliente tenha um alias de ID do cliente além do ID do cliente.

Esta função seria útil ao migrar do servidor de autorização existente para o Authlete e continuar usando os IDs de cliente existentes no novo sistema Authlete.

Por favor, verifique este documento para maiores detalhes.

O Authlete fornece um recurso que permite a um servidor de autorização associar propriedades arbitrárias a um token de acesso ou código de autorização. O servidor de autorização pode compartilhar facilmente as propriedades com servidores de recursos para que eles possam consumir essas informações para a aplicação da autorização, bem como para dar uma resposta.

Por exemplo, você gostaria de desenvolver uma API de transferência de dinheiro que possa processar transações específicas como "enviar $ 50 para a loja ABC." Você poderia implementar essa função criando um escopo "enviar 50 dólares ao abcshop", mas dificilmente funciona, pois você teria que preparar muitos escopos que são multiplicados por destinatários e valores.

Com o recurso de propriedades do Authlete, o servidor de autorização pode associar as informações de transferência de dinheiro (ou seu identificador, se o banco de dados gerenciar as informações reais) com um token de acesso a ser emitido para um cliente. O servidor de recursos, que hospeda a API de transferência de dinheiro, recebe uma solicitação de API com o token de acesso do cliente, pede à API de introspecção de Authlete para fornecer as propriedades junto com os detalhes do token e, em seguida, determina se a solicitação de transferência de dinheiro pode prosseguir .

Verifique este documento para maiores detalhes.

Você pode reduzir o token de acesso e atualizar a duração do token por escopo usando a funcionalidade do atributo de escopo .

Para ativar este recurso, configure um escopo que tenha um atributo de escopo com sua chave de access_token.duration ou refresh_token.duration e o valor de um token “mais curto” duração em segundos. A duração dos tokens com o escopo será a duração definida no atributo de escopo. Consulte este documento para obter mais detalhes.

Além disso, você pode reduzir a duração do token de acesso e do token de atualização por cliente configurando no console de desenvolvedor do cliente.

A rotação de refresh token é um cenário que muitos clientes não conseguem implementar corretamente. A Authlete oferece uma opção para você escolher se realmente os refresh token devem ser trocados ou reutilizar o refresh até que ele expire.

Com essa opção, Authlete somente aceita requisições com code_challenge_method = S256 quando PKCE é utilizado.

Você pode configurar para exigir o método S256 ou mesmo se PKCE é obrigatório na aba “Authorization” do console de proprietário do serviço.

Se configurado o Authlete pode revogar tokens anteriores quando novos tokens forem solicitados. Isso aumenta a segurança do usuário, pois não permite que sessões concorrentes existam.

Authlete permite que as permissões concedidas aos clientes sejam consultados e revogados.

Authlete pode autenticar clientes usando certificados TLS usando o certificado em sí ou uma cadeia de certificados.

As comparações de timestamps em tokens pode ser configurada para estrita ou relaxada em segundos.

Authlete pode ser configurada para rejeitar as requisições de autorização CIBA que não contenham o parametro binding_message.

Certificação OpenID

Authlete implementa diversos dos Perfils para OpenID Provider (OP) da Certificação da OpenID Foundation. Até o momento, Authlete já recebeu as seguintes certificações.

OpenID Certification Version Categories
OpenID Provider 1.1 ~
  • Basic OP
  • Implicit OP
  • Hybrid OP
  • Config OP
2.1 ~
  • Dynamic OP
  • Form Post OP
FAPI OpenID Provider 2.1 ~
  • Financial-grade API (FAPI) 1.0 Second Implementer’s Draft
    • FAPI R/W OP w/ MTLS
    • FAPI R/W OP w/ Private Key
2.2 ~
  • Financial-grade API (FAPI) 1.0 Final
    • FAPI Adv. OP w/ MTLS
    • FAPI Adv. OP w/ MTLS, PAR
    • FAPI Adv. OP w/ Private Key
    • FAPI Adv. OP w/ Private Key, PAR
    • FAPI Adv. OP w/ MTLS, JARM
    • FAPI Adv. OP w/ Private Key, JARM
    • FAPI Adv. OP w/ MTLS, PAR, JARM
    • FAPI Adv. OP w/ Private Key, PAR, JARM
  • UK Open Banking (Based on FAPI 1 Advanced Final)
    • UK-OB Adv. OP w/ MTLS
    • UK-OB Adv. OP w/ Private Key
  • Australia CDR (Based on FAPI 1 Advanced Final)
    • AU-CDR Adv. OP w/ Private Key
    • AU-CDR Adv. OP w/ Private Key, PAR
  • Brazil Open Banking (Based on FAPI 1 Advanced Final)
    • BR-OB Adv. OP w/ MTLS
    • BR-OB Adv. OP w/ Private Key
    • BR-OB Adv. OP w/ MTLS, PAR
    • BR-OB Adv. OP w/ Private Key, PAR
    • BR-OB Adv. OP w/ MTLS, JARM
    • BR-OB Adv. OP w/ Private Key, JARM
    • BR-OB Adv. OP w/ MTLS, PAR, JARM
    • BR-OB Adv. OP w/ Private Key, PAR, JARM
    • BR-OB Adv. OP DCR
  • Financial-grade API (FAPI) 1.0 Second Implementer’s Draft
    • FAPI R/W OP w/ MTLS
    • FAPI R/W OP w/ MTLS, PAR
    • FAPI R/W OP w/ Private Key
    • FAPI R/W OP w/ Private Key, PAR
    • UK-OB R/W OP w/ MTLS
    • UK-OB R/W OP w/ Private Key
    • AU-CDR R/W OP w/ Private Key
    • AU-CDR R/W OP w/ Private Key, PAR
FAPI-CIBA Profile OpenID Provider 2.1 ~
  • FAPI-CIBA OP Poll w/ MTLS
  • FAPI-CIBA OP Poll w/ Private Key
  • FAPI-CIBA OP Ping w/ MTLS
  • FAPI-CIBA OP Ping w/ Private Key

Sumário

Você pode suportar qualquer padrão relacionado a OAuth 2.0 e OpenID Connect se você utilizar Authlete. Inscreva-se e inicie já com nosso guia Inicio rápido.