Table of Contents
Para implementar OAuth 2.0 é implementar dois pontos finais, a fim de emitir um token de acesso. Um é o endpoint de autorização, e o outro é o ponto final token. Estes são chamados OAuth 2.0 pontos finais. RFC 6749, a especificação do OAuth 2.0, descreve como os dois pontos finais devem se comportar.
Para implementar OpenID Connect é estender os dois pontos finais OAuth 2.0, a fim de emitir um ID Token. Núcleo de conexão OpenID 1.0 descreve requisitos adicionais para os dois pontos finais.
Existem outros pontos finais que são definidos pelas especificações, mas são opcionais. A implementação mínima do OAuth 2.0 e do OpenID Connect consiste no ponto final da autorização e no ponto final do token. Se, no entanto, você optar por não apoiar alguns dos tipos de subvenção definidos em RFC 6749, ou o ponto final da autorização ou o ponto final do token podem ser suficientes. Por exemplo, o Subvenção Implícita requer apenas o ponto final de autorização.
O principal objetivo da Authlete é fornecer APIs web que permitem aos desenvolvedores implementar os pontos finais OAuth 2.0 muito facilmente. Além disso, se você usar as implementações padrão dos pontos finais do OAuth 2.0 fornecidos pela Authlete, você não precisa fazer programação.
Uma consequência natural das especificações é que um serviço Web deve gerenciar terceiros aplicativos para clientes. Em um caso típico, um serviço trata seus usuários finais como desenvolvedores e permite que eles registrem aplicativos de clientes.
Authlete fornece APIs da Web para gerenciar (criar / excluir / obter / atualizar) aplicativos de clientes. Você pode ligar diretamente para as APIs da Web ou criar ferramentas usando as APIs da Web, mas a maneira mais simples é usar Console de desenvolvedores Authlete fornece. Desenvolvedores de aplicativos clientes para o seu serviço podem gerenciar seus aplicativos clientes usando o Console do Desenvolvedor.
Um serviço web deve fornecer APIs da Web através das quais os aplicativos do cliente podem acessar os dados do usuário final. Tais APIs são chamadas pontos finais de recursos protegidos.
Um aplicativo cliente acessa um ponto final de recurso protegido com um token de acesso que foi emitido tanto do ponto final da autorização quanto do ponto final do token. A implementação do ponto final de recurso protegido deve verificar se o token de acesso tem privilégios suficientes para acessar o recurso protegido antes de devolver o recurso ao aplicativo do cliente.
A Authlete fornece uma API da Web para obter informações sobre um token de acesso. A implementação de pontos finais de recursos protegidos deve usar a API.
Uma API da Web para obter informações sobre um token de acesso é chamada API de introspecção. Muito recentemente (outubro de 2015), RFC 7662 foi lançada como uma especificação de API de introspecção. A API de introspecção da Authlete é diferente da RFC 7662 mas achamos que os desenvolvedores sentirão que é muito mais útil. Consulte “Nota Técnica” em “Amazon API Gateway + AWS Lambda + OAuth, Resumo” sobre o porquê.