Usando a autenticação baseada em OAuth 2.0 para aplicativos clientes
A Open Authorization (OAuth) 2.0 descreve várias formas pelas quais um proprietário do recurso pode conceder acesso a seus recursos protegidos. IBM® Cloud Pak for Business Automation as a Service suporta apenas o tipo de concessão de credenciais de senha do proprietário do recurso (ROPC) para autenticar o acesso do aplicativo cliente ao ambiente de nuvem.
Tipo de concessão de ROPC
Nos termos 2.0 do OAuth, os aplicativos clientes do Cloud Pak for Business Automation as a Service são clientes confidenciais Para o tipo de concessão ROPC, eles requerem um conjunto de credenciais do cliente (que consistem em um ID do cliente e um segredo do cliente) e um nome do usuário e senha do proprietário do recurso. Para obter as credenciais do cliente, use a API Credentials para gerá-las. Para o nome do usuário e a senha, efetue login no portal em nuvem como o Administrador de conta, gere um conjunto de credenciais de serviço e, em seguida, designe a elas as permissões requeridas pelo aplicativo cliente. As permissões são usadas para controlar o acesso baseado em token OAuth 2.0 para os ambientes em nuvem.
Para obter mais informações sobre o OAuth e o tipo de concessão ROPC, consulte A estrutura de autorização do OAuth 2.0
. Para obter informações sobre a API Credentials , consulte Exemplo: API REST de credenciais para autenticação baseada em OAuth 2.0 e para obter credenciais de serviço, consulte Criação e gerenciamento de contas de serviço.
Gerenciando credenciais do cliente da OAuth 2.0
Os clientes da OAuth 2.0 devem fornecer credenciais do cliente para identificar o contexto do cliente da chamada. Você decide quantos conjuntos de credenciais precisa. Por exemplo, você poderia usar um conjunto para todos os clientes OAuth 2.0 ou ter um conjunto separado de credenciais para cada cliente.
- Obtenha um token de acesso da OAuth 2.0.Use o terminal OAuth 2.0 /token para adquirir um token de acesso incluindo o cliente (ID do cliente e segredo do cliente) e credenciais de serviço (nome de usuário e senha). Por exemplo:
A chamada retorna o token de acesso a ser usado em chamadas da API de operações de nuvem subsequentes, um token de atualização para atualizar o token de acesso e uma duração de validade para o token de acesso. Esteja ciente de que os tokens de acesso geralmente são válidos por minutos ou horas, enquanto os tokens de atualização podem ser válidos por dias. A definição de escopo não é suportada.curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' -d grant_type=password -d client_id=<clientId> -d client_secret=<clientSecret> -d username=<serviceCredId> -d password=<svcCredSecret> https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
Se a chamada for bem-sucedida, o código de resposta HTTP 201 será retornado. Se as credenciais do cliente ou do serviço forem inválidas, a chamada retornará o código de resposta HTTP{"access_token":"CJ7yDymDAfSRz03W7zdX","refresh_token":"fGAv2qzuLnM030Brs8KFaIuY1Kd2P87sLFXI85lH","scope":"","token_type":"bearer","expires_in":1799}*BAD_REQUEST (400). - Use o token para acessar as APIs de operações de nuvem.Include o token de acesso retornado por meio da etapa anterior no cabeçalho Autorização da chamada da API de operações de nuvem. Por exemplo:
Se o token de acesso for inválido tiver expirado, a chamada retornará o código de resposta HTTP 302.curl -k -v -H "Authorization: Bearer CJ7yDymDAfSRz03W7zdX" https://<tenantHost>/baw/dev/rest/bpm/wle/v1/user/current - Atualize o token de acesso usando um token de atualização.Use o terminal OAuth 2.0 /token.
A chamada retorna um novo conjunto de tokens.curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' -d grant_type=refresh_token -d refresh_token=fGU3UjAHG0XKTdnInU8ihqTLf48XJIzQtRUjNFVo -d client_id=<clientId> -d client_secret=<clientSecret> https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/token
A chamada retorna o código de resposta HTTP{"access_token":"DkhN7gg7mk2gsBjGi8ay","refresh_token":"ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC","scope":"","token_type":"bearer","expires_in":1799}BAD_REQUEST (400)se o token de atualização é inválido ou ele já foi usado, ou se as credenciais do cliente são inválidas, por exemplo, porque foram excluídas. - Revogue tokens de atualização e acesso no final do processamento do aplicativo
cliente
Quando o processamento do aplicativo cliente é concluído, é uma boa prática revogar ambos os tokens usando o terminal OAuth 2.0 /revoke. Revogue o token de atualização antes de revogar o token de acesso.
Por exemplo, use a chamada a seguir para revogar o token de atualização:
A chamada sempre retorna um código de resposta HTTP bem-sucedido, por exemplo, 200.curl -k -v -X POST -H 'content-type: application/x-www-form-urlencoded' -d client_id=<clientId> -d client_secret=<clientSecret> -d token=ToY13V2yfoYaeVbBjTwFLhzwX7GiKd7Y801VfjGC https://www.bpm.ibmcloud.com/mga/sps/oauth/oauth20/revokeAtenção: Depois que uma API é acessada, o token de acesso permanece válido até que ele expire.
Limitações
Há um limite diário definido pelo sistema de várias centenas de concessões válidas simultâneas (pares de token de acesso e de atualização). As concessões são controladas pelo aplicativo cliente e pelo nome do usuário do proprietário do recurso. Espera-se que o limite de concessões nunca seja atingido. No entanto, se você vir uma mensagem indicando que o limite de concessões foi atingido, verifique o design de criação de concessão em seus aplicativos clientes ou entrar em contato com o Suporte IBM.