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

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage
• RFC 7009: OAuth 2.0 Token Revocation
• RFC 7523: JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants
• RFC 7591: OAuth 2.0 Dynamic Client Registration Protocol
• RFC 7592: OAuth 2.0 Dynamic Client Registration Management Protocol
• RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
• RFC 7662: OAuth 2.0 Token Introspection
• RFC 8628: OAuth 2.0 Device Authorization Grant
• RFC 8705: OAuth 2.0 Mutual TLS Client Authentication and Certificate Bound Access Tokens
• RFC 8707: Resource Indicators for OAuth 2.0
• RFC 9101: The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
• RFC 9126: OAuth 2.0 Pushed Authorization Requests
• RFC 9207: OAuth 2.0 Authorization Server Issuer Identification
• OAuth 2.0 Multiple Response Type Encoding Practices
• OAuth 2.0 Form Post Response Mode
• OAuth 2.0 Rich Authorization Requests
• OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)
• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0
• OpenID Connect Dynamic Client Registration 1.0
• OpenID Connect Client Initiated Backchannel Authentication Flow - Core 1.0
• OpenID Connect for Identity Assurance 1.0
• Financial-grade API - Part 1: Read-Only API Security Profile
• Financial-grade API - Part 2: Read and Write API Security Profile
• Financial-grade API: JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)
• Financial-grade API: Client Initiated Backchannel Authentication Profile
• UK Open Banking Security Profile
• Australia Consumer Data Right Security Profile
• Open Banking Brasil Financial-grade API Security Profile

Available Soon

• RFC 8693: OAuth 2.0 Token Exchange
• OpenID Connect Core Error Code unmet_authentication_requirements
• OAuth 2.0 Step-up Authentication Challenge Protocol
• Grant Management for OAuth 2.0
• Transformed Claims
• OpenID Connect Federation 1.0

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.

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.