OAuth 2.0
O OAuth 2.0 permite que os usuários acessem recursos da instância por meio de clientes externos, obtendo um token em vez de inserir credenciais de login com cada solicitação de recurso.
Você deve ter a função security_admin para gerenciar a integração do OAuth. Configure o OAuth 2.0 para os seguintes cenários:
- Cenário de cliente OAuth externo (entrada): sua instância fornece um endpoint para que os clientes de terceiros extraiam dados da instância.
- Cenário do provedor OAuth (saída): sua instância extrai dados de um provedor de terceiros.
Tanto as estruturas de segurança simples quanto as estruturas de alta segurança oferecem suporte ao OAuth 2.0. A alta segurança é recomendada. Consulte para obter informações sobre quais versões já têm alta segurança ativa e como ativar a alta segurança.
Principais conceitos da implementação do OAuth 2.0
| Conceito | Descrição |
|---|---|
| Responsável pelo recurso | Uma entidade capaz de conceder acesso a um recurso protegido. Um responsável pelo recurso que seja uma pessoa é chamado de usuário final. O responsável pelo recurso é sempre uma conta de usuário. |
| Cliente | Uma aplicação que, com a autorização do responsável pelo recurso, faça solicitações de recursos protegidos em nome do responsável pelo recurso. |
| Servidor de recursos | O servidor que hospeda os recursos protegidos, capaz de aceitar e responder a solicitações de recursos protegidos. |
| Servidor de autorização | O servidor que emite tokens de acesso para o cliente após a autenticação bem-sucedida do responsável pelo recurso e a obtenção de autorização. |
| Solicitação de autorização | A permissão exigida por um cliente para acessar um recurso protegido. A solicitação de autorização é sempre uma mensagem HTTP POST que contém o ID de cliente que está agindo em nome do responsável pelo recurso e as credenciais que autorizam a solicitação. |
| Concessão de autorização | Uma credencial que representa a autorização do responsável pelo recurso para acessar um recurso. A concessão de autorização são credenciais de login do usuário ou um token de atualização. |
| Token de acesso | Uma cadeia de caracteres segura que um cliente usa para acessar recursos protegidos. Uma instância emite tokens de acesso para clientes que tenham uma concessão de autorização válida. Cada token de acesso tem um escopo, tempo de validade e outros atributos específicos. Por padrão, uma instância emite tokens de acesso com uma vida útil de 30 minutos no cenário em que a instância é o provedor OAuth. Para tokens de terceiros, 30 dias. |
| Token de atualização | Uma credencial que um cliente usa para obter novos tokens de acesso sem exigir autorização adicional do usuário. Uma instância emite um token de atualização para um cliente quando ele é autorizado a ter um token de acesso. Por padrão, uma instância emite tokens de atualização com uma vida útil de 100 dias no cenário em que a instância é o provedor OAuth. Para tokens de terceiros, 365 dias. |
| Certificados autoassinados | A Now Platform não oferece suporte a certificados autoassinados. O cliente OAuth não utiliza o armazenamento confiável do certificado nem permite a conexão com endpoints OAuth que incorporam um certificado autoassinado. |
| Agente do usuário | O usuário que delega direitos de acesso a uma aplicação cliente, que geralmente é um site. Os direitos de acesso permitem que a aplicação cliente ou o site acesse os dados na instância à qual o usuário tem direitos de acesso. O agente do usuário é usado no cenário. |
Tipos de concessão de OAuth
- Código de autorização: o consumidor primeiro obtém um código de autorização e, em seguida, o usa para obter um token de acesso. Você pode especificar um perfil OAuth e especificar este tipo de concessão. O processo que usa o código de autorização também é conhecido como fluxo de código de autenticação ou fluxo de código de autorização.
- Credenciais de senha do responsável pelo recurso: o consumidor do recurso já tem as credenciais do usuário para obter o token de acesso. Este processo também é conhecido como fluxo de senha.
- Credenciais do cliente: o consumidor do recurso usa o ID e o segredo do cliente que já estão configurados no registro do aplicativo.
Armazenamento de credenciais de autenticação básica
O segredo do cliente OAuth é armazenado como um campo do tipo password2, que é criptografado com KMF. As senhas do usuário, que são usadas para verificar as solicitações de endpoint de entrada, são armazenadas como um valor de hash na tabela Usuário em um campo do tipo password (SHA 256). Para obter detalhes sobre essa criptografia, consulte Criptografia de Password2 com KMF.