A autenticação e autorização da IBM Cloud dependem do protocolo padrão de mercado OAuth 2.0. Você pode ler mais sobre o OAuth 2.0 em RFC 6749 — The OAuth 2.0 Authorization Framework. Como a maioria dos adotantes do OAuth 2.0, a IBM também estendeu algumas funcionalidades do OAuth 2.0 para atender aos requisitos da IBM Cloud e de seus clientes.
Acessar e atualizar tokens
Conforme especificado na RFC 6749, os aplicativos recebem um token de acesso para representar a identidade que foi autenticada e suas permissões. Além disso, no IBM Cloud, o token de acesso também representa a conta atual selecionada. Quando os aplicativos chamam o IBM Cloud Services, esse token de acesso é transmitido como parte da chamada de API como cabeçalho de autorização HTTP para fornecer informações sobre o chamador. O IBM Cloud Service de destino tomará sua decisão de autorização com base no conteúdo dentro do token de acesso:
Para casos de uso específicos, os aplicativos também podem recuperar tokens de atualização do IAM. Dessa forma, os aplicativos podem recuperar um novo token de acesso quando o anterior expirar. Isso é importante para o IBM Cloud Console ou a CLI da IBM Cloud, por exemplo, porque, caso contrário, o usuário final precisaria efetuar login novamente após o token de acesso expirar (ou seja, após pelo menos 60 minutos ou até antes). Os tokens de atualização precisam ser armazenados em um local seguro – e mesmo assim, eles eventualmente expiram.
Os aplicativos do cliente no IBM Cloud têm duas maneiras de criar um token de acesso para poder chamar os serviços do IBM Cloud:
1. Use uma chave API para obter um token de acesso (veja aqui para mais informações):
2. Obtenha um token de acesso ao executar em uma plataforma de cálculo gerenciada pela IBM Cloud. Para obter instruções sobre como fazer isso, consulte os seguintes blogs:
Em ambos os casos, o aplicativo terá acesso à chave de API ou ao Compute Resource Token da plataforma de cálculo gerenciada pela IBM Cloud de qualquer maneira. Portanto, não há benefício no armazenamento e uso do token de atualização pelo aplicativo. Quando o aplicativo exigir um novo token de acesso, ele poderá usar a chave de API ou o Compute Resource Token novamente. Portanto, o IBM Cloud IAM não produzirá tokens de atualização para esses casos de uso.
Formato de token
O IBM Cloud foi projetado para escalar. Portanto, os tokens de acesso no IBM Cloud usam o formato JSON Web Token (consulte também RFC 7519). JSON Web Tokens têm um formato padrão:
A assinatura dos tokens de acesso do IBM Cloud é criada usando o algoritmo assimétrico RS256. Isso significa que apenas o IBM Cloud IAM pode assinar esses tokens de acesso, mas qualquer IBM Cloud Service (e até mesmo aplicativos de terceiros) pode verificar a validade de uma assinatura de token usando a parte pública da chave de assinatura. O IBM Cloud IAM anuncia aqui a parte pública das chaves de assinatura atualmente válidas.
Os IBM Cloud Services e outros aplicativos devem fazer download e armazenar em cache essas chaves por uma hora. Usando essas chaves de assinatura pública, eles agora podem validar a assinatura desses tokens. Dessa forma, os IBM Cloud Services e APIs podem validar esses tokens sem qualquer latência relevante. Eles não precisam solicitar ao IAM cada token de acesso para verificar sua validade. Esse método é muito bem dimensionado, pois a carga de validação é ampliada com cada IBM Cloud Service e API. Como consequência, esses tokens de acesso não podem ser revogados – uma revogação exigiria que cada adotante verificasse o token de acesso com o IAM. Tal chamada ao IAM destruiria todas as vantagens descritas acima.
Os tokens de atualização não seguem nenhum formato documentado. Somente o IBM Cloud IAM pode criá-los e compreendê-los. Para obter um novo token de acesso para um token de atualização, o token de atualização precisa ser enviado ao IAM. O IAM validará então o token de atualização e sua entidade relacionada e criará um token de acesso se as diversas validações forem bem-sucedidas. Isso significa que um token de atualização falhará ao criar um novo token de acesso se, por exemplo, o usuário relacionado tiver sido excluído do IBMid ou o ID de serviço relacionado não existir mais.
Sessões de login
Uma sessão de login é criada no momento em que um usuário final está efetuando login no IBM Cloud Console ou no cliente IBM Cloud Command Line Interface (CLI). Um usuário pode visualizar e gerenciar sessões de login usando a interface. O usuário pode encerrar sessões de login individuais usando esta interface de usuário ou obter uma visão geral das sessões de login. Desta forma, o usuário pode revisar e revogar suas sessões de login:
Uma sessão de login terminará se ocorrer um dos seguintes eventos:
A sessão de login está expirando (24 horas por padrão) A sessão de login não foi usada ativamente por um tempo predefinido (duas horas, por padrão) Um usuário efetua logout manualmente de uma sessão de login ou revoga uma sessão de login Muitas sessões de login foram abertas (sem limite, por padrão)
Definir configurações de sessão de login
O administrador IAM de uma conta da IBM Cloud pode configurar determinados parâmetros para sessões de login:
Sessões ativas: Duração máxima de uma única sessão de login. Depois que esse tempo de vida for excedido, a sessão de login será marcada como expirada. Você pode iniciar uma nova sessão de login inserindo as credenciais de login novamente. O padrão é 24 horas. Os administradores do IAM podem estender essa duração para até 720 horas ou reduzi-la para 15 minutos. A Figura 7 acima descreve um cenário em que o tempo de vida padrão de 24 horas foi excedido. Sair por inatividade: uma sessão de login é marcada como ativa com base na interação do aplicativo com o IAM. Por exemplo, o uso de um token de atualização redefine o temporizador de inatividade. O valor para detectar inatividade pode ser definido por um administrador do IAM para pelo menos 15 minutos ou no máximo 24 horas. Por padrão, são usadas duas horas. A Figura 8 acima descreve esse cenário e encerra a sessão de login após duas horas de inatividade. Sessões simultâneas: por padrão, você pode criar um número ilimitado de sessões de login. Pode haver motivos para limitar a quantidade máxima de sessões de login (por exemplo, para limitar o número de scripts executados em paralelo para um determinado usuário). Para este cenário, você pode definir um limite de sessões simultâneas. Se uma nova sessão de login estender o limite de sessões simultâneas, a sessão mais antiga em execução será revogada. O estado da sessão é o mesmo que se ela tivesse sido revogada manualmente, conforme descrito na Figura 9.
As definições de configuração para tokens de acesso e tokens de atualização na seção Expiração de token não estão relacionadas a tokens criados para sessões de login. Essas configurações controlam o comportamento dos tokens que existem sem uma sessão de login conectada. Você encontrará mais detalhes posteriormente neste blog.
Sessões de login e tokens
Conforme explicado anteriormente, o IBM Cloud Console e a CLI da IBM Cloud funcionam internamente com tokens de acesso e atualização para poder chamar o IBM Cloud Services e as APIs do IBM Cloud. O IBM Cloud combina a segurança do modelo OAuth 2.0 com os recursos de gerenciamento de sessões de login.
Para o tempo de login, o aplicativo de chamada (por exemplo, o IBM Cloud Console) obtém um token de acesso e um token de atualização do IAM. Em segundo plano, o IAM inicia uma sessão de login e conecta o token de acesso e atualização à sessão de login. Como os tokens de acesso não podem ser revogados, a vida útil dos tokens de acesso é limitada a 20 minutos ou menos.
Sempre que o token de acesso expirar, o aplicativo chamador deverá usar o token de atualização para obter um novo token de acesso. A sessão possui um temporizador de inatividade que é iniciado no momento do login e redefinido sempre que uma atividade (por exemplo, uma operação de atualização de token) é detectada. A sessão termina se for revogada ativamente, se a expiração geral da sessão for atingida ou se a sessão detectar inatividade. Todos os tokens de atualização param de funcionar se a sessão terminar.
Tokens sem sessões de login
Criar e persistir sessões de login é uma operação que exige muita computação. Portanto, a IBM Cloud não pode criar uma sessão de login para cada interação. Especialmente para invocações de serviço, muitas vezes não há necessidade de sessões de login ou a capacidade de revogar sessões ou atualizar tokens (se forem escolhidos tempos de vida razoáveis).
Tokens de acesso sem tokens de atualização
Se você — conforme descrito no início deste blog — criar um token de acesso usando uma chave de API ou recuperar o token de acesso com base em sua plataforma de computação, não será necessário usar um token de atualização. Você sempre pode criar um novo token de acesso usando a chave de API ou com base no Compute Resource Token fornecido pela plataforma de computação. Portanto, o IBM Cloud IAM não gerará um token de atualização nesses cenários. Além disso, você não criará uma sessão de login em segundo plano.
Acesse e atualize tokens sem sessões de login
Se você efetuar login na CLI do IBM Cloud usando uma chave de API que represente um ID de serviço, essa interação não criará uma sessão de login. No entanto, a CLI espera funcionar por mais tempo do que o necessário para que um token de acesso expire, portanto, a CLI exigirá um token de atualização. O IBM Cloud IAM criará um token de acesso e atualização que não está conectado a uma sessão de login.
Geralmente, espera-se que esses tokens sejam usados apenas dentro de uma CLI e, portanto, em um ambiente que tenha proteção razoável contra uso indevido.
Configurando a expiração do token
As configurações do IAM permitem configurar o tempo de vida para tokens de acesso e tokens de atualização que não possuem sessão de login relacionada:
Tokens de acesso: o tempo de vida dos tokens de acesso criados nesta conta é independente das sessões de login. O valor padrão é 60 minutos. Isso significa que se você estiver criando um token de acesso para uma chave de API, você irá, por padrão, recuperar um token de acesso que será tratado como válido pelos próximos 60 minutos pelo IBM Cloud Services. Se quiser limitar o tempo de vida dos tokens de acesso, você pode escolher um valor menor. Considere escolher um valor que ainda permita executar todos os IBM Cloud Services necessários. Algumas operações de execução mais longa, como pesquisar com o Data Engine dentro de buckets COS, podem parar de funcionar. Tokens de atualização: por padrão, os tokens de atualização são válidos por até 72 horas. Isso significa que se você efetuou login na CLI do IBM Cloud com uma chave de API para um ID de serviço, essa CLI do IBM Cloud poderá continuar funcionando pelas próximas 72 horas, pois poderá atualizar o token de acesso sempre que necessário. Se sua conta não tiver esse requisito, você poderá reduzir o tempo de vida dos tokens de atualização para um valor menor. Considere que isso limita o tempo máximo de execução para serviços de longa execução que usam um token de atualização para prosseguir. Novamente, essa configuração se aplica apenas a tokens de atualização criados independentemente das sessões de login.
Resumo
O IBM Cloud IAM usa tokens de acesso para permitir que os clientes chamem o IBM Cloud Services. Para interações de API, o IBM Cloud IAM evita ao máximo a necessidade de gerar tokens de atualização. Uma exceção a essa regra é o uso de IDs de serviço para operações da CLI do IBM Cloud. Para também permitir interações de longa duração com o IBM Cloud que vão além do tempo de vida de um token de acesso, o IBM Cloud IAM oferece sessões de login que fornecem ao usuário final controle sobre a expiração e revogação da sessão.
Revise as configurações do IAM para ver se elas atendem às suas necessidades:
Lembre-se de que as duas configurações de expiração para tokens de acesso e atualização na seção Expiração do token estão relacionadas apenas a interações de API e sessões de ID de serviço dentro da CLI do IBM Cloud. Sessões normais de usuário no IBM Cloud Console ou em aplicativos semelhantes criarão uma sessão de Login. A expiração dos tokens de acesso e dos tokens de atualização é influenciada indiretamente pelos parâmetros de configuração da sessão em Sessão de login.
Para saber mais, confira estes recursos:
