Documentação do Oracle Cloud Infrastructure

Gerenciando a Autorização Usando a API

A API REST dos domínios de identidade suporta autorização baseada em token e assinaturas de solicitação do OCI. Por motivos de segurança, a API REST dos domínios de identidades não pode ser acessada usando apenas o nome de usuário e a senha que você usa para acessar o domínio de identidades. Para acessar a API REST dos domínios de identidade, você precisa de um token de acesso OAuth2 ou de uma chave de API para usar para autorização.

a API REST dos domínios de identidade usa o protocolo OAuth 2.0 para autenticação e autorização e suporta estes cenários comuns de autorização:

  • servidor Web

  • Mobile

  • Aplicativos JavaScript

A seção Autorização discute os cenários OAuth 2.0 suportados pelos domínios de identidades.

Este seção contém os seguintes tópicos:

Registrando um Aplicativo Cliente

Um aplicativo deve ser registrado como um Cliente OAuth 2 usando o domínio de identidades. Os clientes OAuth são clientes HTTP que podem obter e usar um token de acesso.

Siga as etapas abaixo para usar um cliente OAuth para acessar a API REST de domínios de identidade:

  1. Acesse o domínio de identidades usando o nome de usuário e a senha encontrados no e-mail de Boas-vindas.

  2. Crie um aplicativo cliente OAuth e anote o ID e o segredo do cliente.

    Observação

    Quando você configurar o aplicativo cliente OAuth, selecione as atribuições de aplicativo que deseja designar ao aplicativo. Isso permite ao seu aplicativo acessar as APIs REST que cada uma dessas funções de aplicativo atribuídas pode acessar. Cada atribuição de aplicativo tem escopos atribuídos a ela que definem um nível de acesso ainda mais detalhado às operações de API. Por exemplo, selecione Administrador de Domínio de Identidades na lista. Todas as operações da API REST disponíveis para o administrador do domínio será acessível ao aplicativo.

  3. Use o ID do cliente e o segredo do cliente para solicitar um token de acesso do Serviço OAuth do IAM.

  4. Inclua o token de acesso no cabeçalho HTTP apropriado quando fizer chamadas de API REST.

Mais Informações

Recomendações de Segurança

Para integrar com segurança seus aplicativos a domínios de identidade usando OAuth, implemente controles de segurança recomendados pelo padrão.

Os controles de segurança podem ser considerados obrigatórios ou opcionais, dependendo dos requisitos de confidencialidade, integridade e disponibilidade do seu aplicativo.

Uma integração segura do OAuth requer:

  • Controles de segurança implementados em todos os participantes do OAuth, que incluem o Servidor de Autorização (IAM), o Proprietário do Recurso (usuário), o Cliente e os aplicativos do Servidor de Recursos

  • Confidencialidade das informações-chave: código, access_token, refresh_token, credenciais do cliente e credenciais do usuário

  • Autenticação do servidor estabelecida entre participantes do OAuth (para evitar ataques de personificação)

  • Validação de informações adequadas para qualquer solicitação (especialmente para tokens de acesso do JWT (JSON Web Token)

  • Uso de tokens com escopos mínimos e tempo limite (para reduzir a exposição em caso de divulgação e para dar suporte à revogação de token)

  • Uso de princípios típicos de segurança da informação, como privilégio mínimo

Recursos

Para obter mais informações sobre a segurança do OAuth, acesse os seguintes links:

Observação

Recomendamos que você monitore a segurança de forma proativa para que possa identificar rapidamente novas ameaças de segurança.

Lista de Verificação de Recomendações de Segurança

Esta página lista as recomendações de segurança mais relevantes como uma lista de verificação, para que você possa validar a segurança do aplicativo e tratar os itens de segurança de acordo com suas expectativas.

Criptografia

  • Usar TLS nos Aplicativos Cliente e Servidor de Recursos

    O uso do TLS com todos os aplicativos fornece confidencialidade nas comunicações entre o domínio de identidades, os proprietários de recursos, os aplicativos cliente e os aplicativos do servidor de recursos. Isso impede a espionagem durante a transmissão do código de autorização, tokens de acesso, tokens de atualização, credenciais do cliente e credenciais do usuário, além de impedir ataques de repetição.

  • Estabelecer Autenticação do Servidor (HTTPS com Validação de CA Confiável)

    A autenticação do servidor permite que clientes, servidores de recursos e proprietários de recursos estabeleçam comunicação entre eles mesmos e com um domínio de identidades após verificar o certificado público em relação à CA confiável.

    Se o servidor não fornecer um certificado confiável (fornecido por uma CA confiável e com um nome de host correspondente), a comunicação será considerada um ataque man-in-the-middle.

    A autenticação do servidor impede ataques de spoofing, proxying, man-in-the-middle e phishing para capturar códigos de autorização, tokens de acesso, credenciais do cliente e credenciais do usuário.

  • Considere o Uso de uma Asserção Confiável com Domínios de Identidade

    Os clientes de segurança crítica podem usar uma asserção de cliente com criptografia de chave (em vez de um segredo do cliente) para autenticação.

  • Proteger o URI de Redirecionamento com HTTPS e Validação de CA Confiável

    O HTTPS e o uso da validação de CA confiável impedem o phishing de "código" de autorização e a personificação da sessão do usuário.

Administração

  • Configurar Aplicativos Seguindo o Princípio do Privilégio Mínimo

    Os aplicativos devem ser configurados em um domínio de identidades com apenas os direitos mínimos necessários para sua operação.

    Reduzir o escopo, os fluxos, os tipos de concessão e as operações melhora a postura de segurança e reduz o impacto de um aplicativo comprometido.

  • Fornecer um Nome e uma Descrição Significativos para Aplicativos

    As informações do aplicativo são exibidas para usuários nas páginas Meus Aplicativos e de consentimento.

    O uso de nomes e descrições de aplicativos significativos pode impedir que os usuários cometam erros durante a autorização de consentimento e também contribuir para um melhor relatório de auditoria.

  • Forneça uma Descrição Significativa para Escopos

    A descrição do escopo é exibida na página de consentimento. Explicar o escopo que o usuário está prestes a conceder, de forma compreensível, evita que o usuário cometa erros durante a autorização e contribui para uma melhor geração de relatórios de auditoria.

  • Evite Escopos Fornecidos sem Consentimento

    Para aproveitar a transparência e contar com o proprietário do recurso, forneça escopos sem permissão somente quando um escopo for obrigatório, e o usuário não poderá negá-lo.

  • Reduzir o Tempo Limite do Token de Acesso e Usar Tokens de Atualização

    Os domínios de identidades suportam JWT, um token de acesso que pode ser validado em servidores de recursos sem verificar o token no domínio de identidades. Por causa disso, os tokens de acesso com longa duração não podem ser facilmente revogados.

    Para implementar a revogação oportuna, você pode configurar o token de acesso com uma vida útil curta e, em seguida, usar o token de atualização para solicitar novos tokens de acesso. Para executar uma revogação oportuna, você precisa revogar o token de atualização.

  • Rotacionar os Segredos do Cliente do Aplicativo

    Para implementações críticas de segurança, implemente uma rotação de segredo do cliente. Isso reduz o risco de um segredo de cliente comprometido ser explorado.

Proprietário do Recurso (Usuário)

  • Manter o Proprietário do Recurso Informado

    O uso do escopo com consentimento fornece transparência ao proprietário do recurso e impede que os aplicativos solicitem escopos que não sejam necessários.

  • Conhecimento do usuário

    Ensine os usuários a proteger suas credenciais e identificar o cliente, o aplicativo do servidor de recursos e a legitimidade do domínio de identidades (especialmente quando as páginas de autenticação e consentimento aparecerem). Isso reduz o risco de ataques de phishing e o comprometimento das credenciais do usuário.

Desenvolvimento de Aplicativos

  • Proteger códigos, tokens de acesso, tokens de atualização e credenciais do cliente

    Os aplicativos devem preservar a confidencialidade dos códigos, tokens de acesso, tokens de atualização e credenciais do cliente. Ao desenvolver o aplicativo, considere as seguintes medidas (entre outras medidas de segurança do aplicativo):

    • Não armazenar códigos (use o código somente durante o runtime para obter o token de acesso)

    • Mantenha tokens de acesso em memória transitória e limite suas concessões

    • Armazene tokens de atualização e credenciais do cliente em locais seguros que só podem ser acessados pelo aplicativo

  • Proteger o URL de redirecionamento

    O URL de redirecionamento (de onde o domínio de identidades recupera o código de autorização) é considerado um componente-chave para segurança do OAuth. Tenha cuidado ao definir este URL para evitar ameaças como falsificação de solicitações entre sites e negação de serviço.

  • Ler Tokens do Sistema de Arquivos de Aplicativos Nativos

    Os hackers podem tentar obter acesso ao sistema de arquivos no dispositivo e ler os tokens de atualização usando um aplicativo malicioso. Para reduzir esse risco, armazene segredos em armazenamento seguro e use o bloqueio do dispositivo para impedir o acesso não autorizado ao dispositivo.

  • Implementar Controles para Dispositivos Clonados e Roubados com Aplicativos Nativos

    Para reduzir os riscos quando um dispositivo com Aplicativos Nativos é clonado ou roubado, use o bloqueio do dispositivo para evitar acesso não autorizado e revogar tokens de atualização.

  • Validar a Segurança do Aplicativo Antes da Publicação

    Teste a segurança do aplicativo e do ambiente de hospedagem antes de publicar o aplicativo para reduzir vulnerabilidades. As ameaças relacionadas à hospedagem e ao desenvolvimento de aplicativos não são tratadas pelos domínios de identidade. Essas ameaças incluem, mas não se limitam a, acesso indireto a bancos de dados e armazenamento de aplicativos, sequestro de seleção, script entre sites, injeção de script/SQL e fluxos de confidencialidade de informações no aplicativo.

  • Aplicar Privilégio Mínimo Durante a Solicitação de Escopo

    Os aplicativos clientes devem solicitar tokens que contenham apenas escopos que possivelmente ou realmente usarão.

    O uso do urn:opc:idm:__myscopes__ scope, embora conveniente, pode recuperar mais tokens do que o necessário pelo aplicativo cliente.

    Um token com extensos escopos pode aumentar o impacto de segurança quando um token é comprometido.

    Consulte Escopos para obter informações sobre como usar o parâmetro de escopo e um token de acesso para conceder diferentes níveis de acesso a domínios de identidades.

  • Validar Tokens JWT

    Ao receber um token de acesso (JWT) de qualquer parte (exceto o servidor de domínio de identidades em uma solicitação direta do seu aplicativo), valide o JWT seguindo o Perfil JWT para Concessões de Autenticação e Autorização do Cliente OAuth 2.0 e as RFCs JWT.

    Consulte Validação de Token para obter mais informações sobre como validar o token.

    Observação

    Os servidores de recursos devem processar informações somente após a execução de toda a validação do JWT.

  • Receber Tokens JWT Corretamente

    Os aplicativos do servidor de recursos devem receber o token de acesso usando apenas o cabeçalho Authorization: bearer <token> para evitar ameaças relacionadas ao armazenamento em cache de parâmetros.

  • Implementar TLS de 2 Fases entre Aplicativos Cliente e Servidor de Recursos

    Para aplicativos críticos de segurança, você pode implementar um TLS 2-way entre aplicativos cliente e servidor de recursos para reduzir o risco de ataques de negação de serviço (DoS) e personificação.

    Não escreva aplicativos que coletem informações de autenticação diretamente dos usuários.

  • Impedir Seleção-Jacking

    Para navegadores mais recentes, evite o iFrames durante a autorização impondo o uso do cabeçalho X-FRAME-OPTIONS.

    Para navegadores mais antigos, as técnicas de quebra de quadro JavaScript podem ser usadas, mas podem não ser eficazes em todos os navegadores.

  • Evite o Uso de Credenciais de Senha do Proprietário do Recurso

    O fluxo do proprietário do recurso permite que um cliente solicite um token de acesso usando o ID de um usuário final, a senha e as próprias credenciais do cliente. Este tipo de concessão apresenta um risco maior porque:

    • É responsável por coletar as credenciais do usuário no aplicativo cliente (mantém o anti-padrão de UID/senha).

    • Não apresenta uma tela de consentimento para solicitações de escopo.

    Exceto por motivos de migração, evite o uso desse tipo de concessão.

  • Usar o Cabeçalho Cache-Control="no-store"

    Este cabeçalho minimiza o risco de não proteger conteúdo autenticado e vazar dados confidenciais em proxies HTTP.

  • Evitar solicitações com informações confidenciais enviadas usando parâmetros de URL

    Os parâmetros de URL (usados em solicitações GET) podem ser registrados em qualquer componente entre aplicativos, como logs de aplicativos, servidores proxy, firewalls e componentes de borda de rede.

    Os domínios de identidades implementam pontos finais REST de pesquisa alternativos usando o POST que aborda esse risco. Consulte a página Parâmetros de Consulta para obter mais informações.