Esta página foi traduzida pela API Cloud Translation.

Como implementar o tipo de concessão de senha

Esta é a documentação do Apigee Edge.
Acesse Documentação da Apigee X. informações

O tipo de concessão de senha (ou "senha") do proprietário do recurso é usado principalmente nos casos em que o aplicativo é altamente confiável. Nessa configuração, o usuário fornece as credenciais do servidor de recursos (nome de usuário/senha) ao aplicativo cliente, que as envia em uma solicitação de token de acesso ao Apigee Edge. Um servidor de identidade valida as credenciais e, se forem válidas, o Edge continua a produzir um token de acesso e as retorna ao aplicativo.

Sobre este tópico

Neste tópico, você encontra uma descrição e uma visão geral do fluxo de tipo de concessão de senha do proprietário do recurso do OAuth 2.0, além de discutir como implementar esse fluxo no Apigee Edge.

Exemplos que podem ser úteis

Como solicitar um token de acesso: tipo de concessão de senha: mostra como formar uma solicitação de token, configurar a política OAuthV2 para o tipo de concessão de senha e como configurar um endpoint para a política no Edge.
oauth-validate-key-secret: um exemplo de proxy no GitHub que é possível implantar no Edge e testar. Esse é um exemplo completo que mostra o tipo de concessão da senha. Ele demonstra uma prática recomendada, que é autenticar as credenciais do app cliente (chave/secret) antes de enviar as credenciais do usuário a um provedor de identidade.

Vídeo

Vídeo : confira este vídeo sobre como implementar o tipo de concessão de senha.

Casos de uso

Esse tipo de concessão é destinado a aplicativos altamente confiáveis ou com privilégios porque o usuário precisa fornecer as credenciais do servidor de recursos ao aplicativo. Normalmente, o aplicativo fornece uma tela de login em que o usuário insere as credenciais.

Diagrama de fluxo

O diagrama de fluxo a seguir ilustra o fluxo de concessão de senha do proprietário do recurso com o serviço Apigee Edge como o servidor de autorização.

Dica: para ver uma versão maior desse diagrama, clique com o botão direito nele e abra-o em uma nova guia ou salve-o e abra-o em um visualizador de imagens.

Etapas no fluxo de tipo de concessão de senha

Veja um resumo das etapas necessárias para implementar o tipo de concessão de senha em que o Apigee Edge funciona como o servidor de autorização.

Pré-requisito: o app de cliente precisa ser registrado no Apigee Edge para receber o ID e as chaves secretas do cliente. Consulte Como registrar aplicativos de cliente para detalhes.

1. O usuário inicia o fluxo e insere as credenciais

Quando o app precisa acessar os recursos protegidos do usuário, por exemplo, o usuário clica em um botão no app, o usuário é redirecionado para um formulário de login.

2. O app solicita um token de acesso do Apigee Edge

O app envia uma solicitação de token de acesso, incluindo as credenciais do usuário, para um endpoint GenerateAccessToken no Apigee Edge.

Veja um exemplo de solicitação POST que inclui os parâmetros necessários para esse tipo de concessão:

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -H 'Authorization: Basic c3FIOG9vSGV4VHo4QzAySVg5T1JvNnJoZ3ExaVNyQWw6WjRsanRKZG5lQk9qUE1BVQ' \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

Como alternativa, esse comando pode ser executado da seguinte forma, usando a opção -u para curl para criar o cabeçalho de autenticação básica codificado em base64.

$ curl -i \
  -X POST \
  -H 'Content-Type: application/x-www-form-urlencoded' \
  -u sqH8ooHexTz8C02IX9ORo6rhgq1iSrAl:Z4ljtJdneBOjPMAU \
  -d 'grant_type=password&username=the-user-name&password=the-users-password' \
  https://docs-test.apigee.net/oauth/token

Cada um desses comandos deve estar em uma única linha.

As credenciais do usuário estão contidas nos parâmetros do formulário, enquanto as credenciais do cliente são codificadas no cabeçalho de autenticação básico de HTTP. Para uma descrição detalhada dessa chamada de API, incluindo detalhes sobre o cabeçalho Basic Auth necessário, consulte a seção "Como solicitar tokens de acesso e códigos de autorização".

3. O Edge valida o app cliente

Antes de enviar o nome de usuário e a senha a um provedor de identidade, o Edge precisa saber se o aplicativo cliente que está fazendo a solicitação é válido e confiável. Uma maneira de fazer isso é usar a autenticação de chaves de API na chamada de API. Em alguns casos, convém validar a chave e o segredo do cliente. Há um proxy de exemplo que ilustra essa técnica de tolerância no repositório api-platform-samples no GitHub.

4. O Edge processa as credenciais de login

Depois que o app cliente for validado, será possível usar uma chamada de serviço ou uma política JavaScript para chamar o serviço de identidade, enviando as credenciais do usuário. Por exemplo, ele pode ser um serviço LDAP ou qualquer serviço que você queira usar para validar as credenciais. Para detalhes sobre essas políticas, consulte Política de extração de variáveis e política JavaScript.

Se o serviço de identidade validar as credenciais e retornar uma resposta 200, o Edge continuará processando a solicitação. Caso contrário, o Edge interromperá o processamento e retornará um erro ao app cliente.

5. A política OAuthV2 é executada

Se as credenciais forem válidas, a próxima etapa de processamento será executar uma política OAuthV2 configurada para o tipo de concessão de senha. Veja um exemplo: Os elementos <UserName> e <PassWord> são obrigatórios, e é possível recuperá-los das variáveis de fluxo que foram salvas com a política ExtractVariables. Para informações detalhadas de referência sobre essa política, consulte a política do OAuthV2.

<OAuthV2 name="GetAccessToken">
  <Operation>GenerateAccessToken</Operation>
  <ExpiresIn>360000000</ExpiresIn> 
  <SupportedGrantTypes> 
     <GrantType>password</GrantType> 
  </SupportedGrantTypes> 
  <GrantType>request.queryparam.grant_type</GrantType> 
  <UserName>login</UserName>
  <PassWord>password</PassWord>
  <GenerateResponse/> 
</OAuthV2>

Se essa política for bem-sucedida, uma resposta será gerada de volta ao cliente que contém um token de acesso. A resposta está no formato JSON. Veja um exemplo: Observe que access_token é um dos elementos:

{
    "issued_at": "1420258685042",
    "scope": "READ",
    "application_name": "ce1e94a2-9c3e-42fa-a2c6-1ee01815476b",
    "refresh_token_issued_at": "1420258685042",
    "status": "approved",
    "refresh_token_status": "approved",
    "api_product_list": "[PremiumWeatherAPI]",
    "expires_in": "1799",
    "developer.email": "tesla@weathersample.com",
    "organization_id": "0",
    "token_type": "BearerToken",
    "refresh_token": "IFl7jlijYuexu6XVSSjLMJq8SVXGOAAq",
    "client_id": "5jUAdGv9pBouF0wOH5keAVI35GBtx3dT",
    "access_token": "I6daIgMSiUgYX1K2qgQWPi37ztS6",
    "organization_name": "docs",
    "refresh_token_expires_in": "0",
    "refresh_count": "0"
}

6. O cliente chama a API protegida

Agora, com um código de acesso válido, o cliente pode fazer chamadas à API protegida. Nesse cenário, as solicitações são feitas para o Apigee Edge (o proxy), e o Edge é responsável por validar o token de acesso antes de passar a chamada de API para o servidor de recursos de destino. Os tokens de acesso são transmitidos em um cabeçalho de autorização. Exemplo:

$ curl -H "Authorization: Bearer I6daIgMSiUgYX1K2qgQWPi37ztS6
" http://{org_name}-test.apigee.net/weather/forecastrss?w=12797282