Esta página se aplica à Apigee e à Apigee híbrida.
Confira a documentação da Apigee Edge.
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. Um servidor de identidade valida as credenciais e, se forem válidas, a Apigee 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.
Exemplos que podem ser úteis
- Usar o 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 na Apigee.
- oauth-validate-key-secret: um exemplo de proxy no GitHub que é possível implantar na Apigee 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 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 funciona como o servidor de autorização.
Pré-requisito: o app de cliente precisa ser registrado na Apigee 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
O app envia uma solicitação de token de acesso, incluindo as credenciais do usuário, para um endpoint GenerateAccessToken no Apigee.
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 ver uma descrição detalhada dessa chamada de API, incluindo detalhes sobre o cabeçalho obrigatório de autenticação básica, consulte a seção de concessão de senha de Receber tokens do OAuth 2.0.
3. A Apigee valida o aplicativo 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. A Apigee 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, a Apigee continuará processando a solicitação. Caso contrário, a Apigee 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 a Apigee (o proxy), e a Apigee é 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