O que é OAuth? Acesso Delegado, Tokens e Fluxos PKCE

O Scrapeless Agent Browser suporta navegação em navegador e fluxos de trabalho baseados em sessão, enquanto as permissões de OAuth permanecem responsabilidade do aplicativo e do authorization server.

OAuth é um framework para autorização delegada

OAuth é um framework de autorização que permite que um aplicativo obtenha acesso limitado a recursos protegidos sem coletar a senha do resource owner para esses recursos. Um usuário pode autorizar, por exemplo, uma ferramenta de agendamento a ler um calendário, enquanto o serviço de calendário controla as operações permitidas. A ferramenta de agendamento recebe uma credencial para esse acesso em vez da senha reutilizável do usuário.

O framework de autorização OAuth define os papéis e as interações centrais. O resource owner controla o recurso relevante, o aplicativo cliente solicita acesso, o authorization server concede credenciais sob sua política, e o resource server hospeda a API protegida. Uma organização pode operar ambos os papéis de servidor, mas manter os papéis distintos ajuda a explicar onde ocorrem autenticação, decisões de permissão e validação de token.

Uma concessão de token é mais restrita que uma permissão ampla para operar uma conta. O acesso pode ser limitado por escopo, recurso pretendido, duração e pela política do authorization server. O resource server ainda verifica se a operação é permitida. Uma tela de consentimento descreve o acesso solicitado, enquanto a credencial efetivamente concedida e a aplicação da política pelo servidor determinam o que o aplicativo pode fazer após o consentimento.

Autorização e autenticação respondem a perguntas diferentes

Autorização determina qual acesso um aplicativo pode exercer; autenticação estabelece uma identidade em um contexto específico. OAuth pode envolver um usuário fazendo sign-in no authorization server, mas essa interação não fornece automaticamente ao cliente uma asserção de identidade padronizada adequada para o próprio sistema de login. Tratar um access token arbitrário como prova de login pode criar problemas de substituição de token e de audiência.

A camada de identidade OpenID Connect adiciona autenticação sobre o OAuth e define um ID token para o cliente validar. Um access token é destinado a um resource service, enquanto um ID token atende ao contexto de autenticação do cliente. A distinção é visível nos padrões e deve permanecer visível no design do aplicativo. Enviar um ID token para uma API não relacionada não é equivalente a apresentar o access token correto.

Para um produto de sign-in, selecione uma integração de provedor que suporte explicitamente o protocolo de identidade exigido e valide seus tokens usando esse protocolo. Para acesso delegado a APIs, solicite as permissões mínimas apropriadas e envie a credencial de acesso resultante apenas para o serviço pretendido. Um único botão voltado ao usuário pode ocultar ambos os fluxos, portanto inspecione o contrato real em vez de chamar toda ação de social sign-in simplesmente de OAuth login.

Um Authorization Code separa o consentimento no navegador do uso do token

O authorization code flow direciona o usuário através do authorization server, que autentica o usuário conforme necessário e avalia a solicitação de acesso. Após a aprovação, o navegador retorna ao local de redirect registrado do cliente com um authorization code de curta duração. O cliente então troca esse code no token endpoint, usando os parâmetros e a autenticação apropriados ao seu tipo de cliente.

Um code não é a credencial de API usada para ler entradas de calendário ou outros registros protegidos. Seu propósito é conectar a interação de autorização pelo front-channel com a troca de token subsequente. Mantenha a validação do redirect URI rigorosa e vincule a resposta à transação que o cliente iniciou. Um callback recebido em uma origem inesperada ou sem o contexto de transação esperado não deve se tornar uma sessão de aplicativo autenticada.

Um registro de cliente descreve detalhes como seus locais de redirect e concessões permitidas. Um aplicativo de servidor que pode proteger credenciais e um aplicativo público entregue em navegador têm capacidades diferentes. Não copie um client secret de servidor para JavaScript baixável. O modelo de distribuição do aplicativo determina se esse valor pode ser mantido em sigilo, independentemente do rótulo atribuído a ele em um dashboard.

PKCE protege a troca de code

PKCE, ou Proof Key for Code Exchange, vincula a solicitação de autorização e a troca de token usando um verifier específico da transação. O cliente deriva um challenge a partir do verifier e inclui o challenge na solicitação de autorização. No token endpoint ele fornece o verifier, permitindo que o servidor confirme que a troca pertence à mesma transação iniciadora.

O mecanismo PKCE trata da interceptação de authorization codes. PKCE não transforma um aplicativo público em um confidential client, e o verifier não é uma senha permanente de cliente. Gere e retenha-o dentro da transação específica, mantenha-o protegido e use um método de challenge compatível que não exponha o verifier na solicitação de autorização.

A prática recomendada atual de segurança em OAuth exige PKCE para clientes públicos no fluxo de código de autorização e o recomenda para clientes confidenciais. Também aborda correspondência exata de redirecionamento, injeção de código e vazamento de tokens. Aplique esses requisitos por meio de uma implementação OAuth mantida em vez de montar um fluxo a partir de trechos vagamente relacionados. Bibliotecas corretas ainda precisam de emissor, redirecionamento e configuração de recurso corretos.

Tokens de acesso e tokens de atualização têm ciclos de vida separados

Um token de acesso carrega ou referencia a autorização necessária por um serviço de recurso. Seu formato não é fixado pelo framework OAuth geral: um serviço pode usar um valor opaco ou um token estruturado. O cliente deve depender de campos de resposta documentados e requisitos do recurso em vez de assumir que todo token de acesso é um JSON Web Token legível.

Um token de atualização é uma credencial diferente usada com o servidor de autorização para obter tokens de acesso. Ele não deve ser enviado para a API comum de recursos. Se o servidor emite um, por quanto tempo permanece válido e quais proteções se aplicam dependem da política do cliente e do provedor. Proteja-o como um segredo valioso, porque seu ciclo de vida pode se estender além do de um único token de acesso.

A revogação também tem uma interface definida em vez de ser implicada pela exclusão de uma string local. O mecanismo de revogação de token OAuth permite que um cliente notifique o servidor de autorização de que um token não é mais necessário. Logout local, revogação de concessão e término de cada sessão de aplicativo podem ter efeitos diferentes. Documente esses efeitos para que os usuários entendam o que a desconexão de uma integração realmente altera.

Escopo, público e política do servidor limitam o acesso

Os escopos descrevem capacidades solicitadas ou concedidas dentro do vocabulário do sistema de autorização. Seus nomes e significados pertencem ao provedor. Um escopo orientado a leitura ainda pode expor registros sensíveis, portanto solicite apenas o que o recurso do produto exige e explique o porquê. Um aplicativo não deve pedir permissões amplas de escrita apenas porque isso torna o desenvolvimento futuro mais fácil.

O recurso ou público pretendido é outro limite. Um token emitido para um serviço não deve ser aceito como autorização intercambiável em outro serviço. Servidores de recurso devem validar o emissor, o público, a expiração e os detalhes de autorização relevantes usando o mecanismo de token selecionado. Uma assinatura válida por si só não estabelece que uma credencial é apropriada para a operação solicitada.

Fluxos de credenciais de cliente tratam do acesso de aplicativos em contextos que não representam o consentimento delegado de um usuário. Fluxos orientados a dispositivo tratam de outras restrições de interação. Escolha uma concessão com suporte para o tipo real de aplicativo em vez de forçar todos os produtos por um fluxo familiar. A presença de OAuth na documentação de um serviço não significa que toda concessão, escopo ou tipo de cliente está disponível para todas as contas.

Mantenha o estado do navegador separado das credenciais OAuth

Cookies do navegador, uma sessão de aplicativo e credenciais OAuth são preocupações de implementação relacionadas com ciclos de vida diferentes. Um navegador pode permanecer conectado enquanto um token de API expira, e um aplicativo pode manter um token delegado válido depois que uma determinada visualização do navegador é fechada. Diagnose falhas de permissão no componente que possui a credencial relevante em vez de copiar o estado do navegador para serviços não relacionados.

Os requisitos de manipulação de chave de API do Scrapeless descrevem uma credencial separada usada para acessar produtos Scrapeless. Uma chave de API do Scrapeless não é um token de acesso OAuth para o site de destino. Os métodos de autenticação de API relacionados ajudam a distinguir esquemas de credencial, e preços do Scrapeless cobrem o uso do serviço em vez de direitos de autorização de terceiros.

Revise uma integração delegada antes de expandi-la

Uma integração delegada deve ter um inventário claro de permissões. Registre o emissor, recursos pretendidos, escopos solicitados, tipo de cliente, locais de redirecionamento, armazenamento de credenciais e comportamento de desconexão. Separe a telemetria comum do aplicativo dos dados de requisições que carregam tokens, para que logs rotineiros não se tornem um repositório de credenciais fora de controle. Teste limites de permissão com contas autorizadas e níveis de acesso documentados.

Uma integração hipotética com calendário pode começar com acesso somente leitura para um recurso aprovado pelo usuário. Seus critérios de aceitação devem incluir a conta correta, os recursos de calendário permitidos, um caminho funcional de desconexão e a ausência de segredos em logs visíveis ao cliente. Expanda as permissões apenas quando um recurso concreto as exigir. Essa disciplina torna o pedido de consentimento mais fácil de explicar e limita as consequências de uma exposição de credenciais.

Conclusão

OAuth delega acessos específicos por meio de funções definidas, credenciais e política do servidor. Escolha o fluxo apropriado ao tipo real de cliente, use PKCE quando exigido e mantenha asserções de identidade separadas de tokens de acesso a recursos. Uma integração sustentável torna claros seus escopos, limites de armazenamento e comportamento de desconexão antes de lidar com dados sensíveis de contas.