Dica

Guia de Compra de Ferramentas Elétricas

Guia completo para você escolher ferramentas de acordo com sua necessidade.

Ler dica

Dica

Cartões SD Sandisk Piratas

Dicas que podem auxiliar a escolher o melhor dispositivo e evitar os piratas!

Ler dica

Educação

Organizando os desenhos

Organizar esses desenhos tem sido um desafio em tempos de confinamento...

Ler dica

Internet

Template html básico para Arduino, ESP82

O básico pra quem esta com pressa!

Ler dica

Viagem

Como embalar malas para viagem

Embale malas para viagem como os serviços de aeroportos fazem

Ler dica

Tecnologia

Como deixar o libreoffice em pt-br

O LibreOffice é uma alternativa gratuita

Ler dica

Cozinha

Como economizar detergente

Aproveitar melhor o uso do sabão na hora de lavar louça

Ler dica

Casa

Como limpar sua grelha da churrasqueira

Faça uma limpeza rápida e prática da sua grelha

Ler dica

Automóvel

Remova riscos da lataria do carro

Remova riscos da lataria do seu carro facilmente com óleo lubrificante

Ler dica

Meio Ambiente

Reaproveitando o rolinho de papel

Algumas dicas de como reutilizar o rolinho do papel higiênico

Ler dica

Dica

Tire o cheiro de alho das mãos

Uma dica super fácil e funcional

Ler dica

Eletrônica

Pré-amplificador de áudio

Pré-amplificador de áudio para microfones de eletreto

Ler dica

Programação

SSO com SAML e OIDC: como funciona o login único nas empresas

Quem já trabalhou em uma empresa de médio ou grande porte provavelmente conhece a experiência de fazer login uma única vez e, a partir daí, acessar o e-mail, o sistema de chamados, a intranet e outras ferramentas sem precisar digitar senha de novo em cada uma. Esse mecanismo se chama Single Sign-On, ou SSO. O funcionamento gira em torno de dois papéis. Existe um provedor de identidade central (Identity Provider, ou IdP), que é quem realmente autentica o usuário, e várias aplicações (Service Providers, ou SPs) que confiam nesse provedor central em vez de terem seu próprio sistema de login. O SAML (Security Assertion Markup Language) é o protocolo mais tradicional para implementar esse modelo, muito comum em ambientes corporativos. Ele usa mensagens em XML chamadas "asserções", assinadas digitalmente pelo provedor de identidade, confirmando quem é o usuário. <?php use OneLoginSaml2Auth; $auth = new Auth($configSaml); // endpoint que recebe a resposta do provedor de identidade $auth->processResponse(); if (!$auth->isAuthenticated()) { exit('Falha na autenticacao SAML.'); } $atributos = $auth->getAttributes(); $nameId = $auth->getNameId(); session_start(); $_SESSION['usuario_id'] = criarOuAtualizarUsuarioLocal($nameId, $atributos); Já o SSO baseado em OpenID Connect segue a mesma lógica geral, mas usando tokens JSON em vez de mensagens XML. Um provedor de identidade central (como Keycloak, Azure AD ou Google Workspace) emite um ID Token que qualquer aplicação da organização pode validar, sem precisar reimplementar login algum. Uma vantagem prática do OIDC nesse cenário é a possibilidade de verificar, de forma silenciosa, se já existe uma sessão ativa no provedor, sem exibir nenhuma tela de login para o usuário caso ele já esteja autenticado em outro sistema da empresa. Na escolha entre os dois, SAML costuma aparecer em integrações com sistemas corporativos mais antigos e setor público, enquanto OIDC tende a ser a opção mais simples e mais usada em implementações novas, por depender de JSON e HTTP, tecnologias já bem conhecidas de quem desenvolve aplicações web.

Ler dica

Programação

OAuth 2.0 e OpenID Connect: qual a diferença e quando usar cada um

É comum ver os termos OAuth 2.0 e OpenID Connect sendo usados como se fossem sinônimos, mas eles resolvem problemas diferentes. Entender essa diferença ajuda a escolher a ferramenta certa na hora de implementar login em um sistema. O OAuth 2.0 foi criado para resolver um problema de autorização: permitir que uma aplicação acesse recursos em nome de um usuário, sem que essa aplicação precise conhecer a senha dele. É o que acontece, por exemplo, quando você autoriza um aplicativo a acessar seus contatos ou seus arquivos em um serviço de nuvem. O fluxo mais usado hoje é o chamado Authorization Code com PKCE. De forma resumida: o usuário é redirecionado para o provedor, autoriza o acesso, volta para a aplicação com um código temporário, e esse código é trocado por um token de acesso em uma chamada direta entre servidores. <?php $code = $_GET['code'] ?? null; $ch = curl_init('https://provedor.com/oauth/token'); curl_setopt_array($ch, [ CURLOPT_POST => true, CURLOPT_RETURNTRANSFER => true, CURLOPT_POSTFIELDS => http_build_query([ 'grant_type' => 'authorization_code', 'code' => $code, 'redirect_uri' => $redirectUri, 'client_id' => $clientId, 'client_secret' => $clientSecret, ]), ]); $resposta = json_decode(curl_exec($ch), true); $accessToken = $resposta['access_token'] ?? null; O OpenID Connect (OIDC) entra como uma camada construída em cima do OAuth 2.0, adicionando justamente o que faltava: uma forma padronizada de autenticar o usuário. Ele acrescenta o chamado ID Token, um token assinado contendo informações de identidade, como e-mail e nome. Na prática, o resumo é este: o OAuth2 responde "o que essa aplicação pode fazer em nome do usuário", enquanto o OIDC responde "quem é essa pessoa". É por isso que qualquer botão de "Entrar com Google" ou "Entrar com GitHub" é, tecnicamente, uma implementação de OpenID Connect, mesmo usando toda a estrutura do OAuth 2.0 por baixo. Se o seu objetivo é apenas dar acesso a um recurso específico (como uma agenda ou um repositório), OAuth 2.0 puro já resolve. Se o objetivo é efetivamente autenticar o usuário e saber quem ele é, o caminho correto é OpenID Connect.

Ler dica

Programação

Access Token e Refresh Token: como manter o usuário logado com segurança

Um problema prático de usar apenas um token com tempo de vida curto é ter que pedir para o usuário fazer login de novo a cada poucos minutos. A solução adotada pela maioria dos aplicativos modernos é separar a autenticação em dois tokens com funções diferentes: o access token e o refresh token. O access token tem vida curta, geralmente entre 5 e 30 minutos, e é usado em cada requisição para provar que o usuário está autenticado. O refresh token, por sua vez, tem vida bem mais longa (dias ou semanas) e serve unicamente para buscar um novo access token quando o antigo expira, sem precisar pedir senha novamente. Veja um exemplo simples de emissão e renovação desses tokens em PHP: <?php function emitirTokens(int $usuarioId, string $chaveSecreta): array { $accessToken = gerarJwt($usuarioId, $chaveSecreta); $refreshToken = bin2hex(random_bytes(48)); salvarRefreshToken($usuarioId, hash('sha256', $refreshToken), '+30 days'); return ['access_token' => $accessToken, 'refresh_token' => $refreshToken]; } // endpoint responsavel por renovar o access token $refreshEnviado = $_POST['refresh_token'] ?? ''; $registro = buscarRefreshTokenValido(hash('sha256', $refreshEnviado)); if (!$registro || $registro['expira_em'] < time()) { http_response_code(401); exit(json_encode(['erro' => 'Refresh token invalido ou expirado'])); } // boa pratica: invalidar o token antigo e emitir um novo par revogarRefreshToken($registro['id']); $novosTokens = emitirTokens($registro['usuario_id'], $chaveSecreta); echo json_encode($novosTokens); Um detalhe que faz muita diferença na segurança é a rotação do refresh token: a cada uso, o token antigo é invalidado e um novo é emitido. Se, por algum motivo, um refresh token roubado for usado depois do legítimo, o sistema consegue perceber essa reutilização indevida e revogar toda a cadeia de tokens daquele usuário. Esse modelo é hoje o padrão em aplicativos mobile e single-page applications, porque equilibra bem dois objetivos que parecem opostos: manter o usuário logado por muito tempo, sem abrir mão de conseguir revogar o acesso rapidamente quando necessário.

Ler dica

Programação

Tokens Bearer e JWT: entenda a autenticação sem estado

Conforme as aplicações foram deixando de ser só páginas web e passaram a incluir apps mobile, integrações e microsserviços, um novo problema apareceu: como autenticar sem depender de sessão guardada no servidor? A resposta mais popular hoje é o token Bearer, especialmente na forma de JWT. Um token Bearer funciona de um jeito bem direto: quem apresenta o token é considerado autenticado. Ele é enviado em todas as requisições dentro do cabeçalho Authorization, assim: Authorization: Bearer <token>. O JWT (JSON Web Token) é o formato mais usado de token Bearer hoje. Ele é dividido em três partes separadas por ponto, cada uma codificada em Base64: um cabeçalho, um conjunto de informações (chamadas de claims, como o ID do usuário e a data de expiração) e uma assinatura que garante que ninguém alterou o conteúdo pelo caminho. Um exemplo de geração e validação de JWT em PHP, usando a biblioteca firebase/php-jwt: <?php use FirebaseJWTJWT; use FirebaseJWTKey; function gerarJwt(int $usuarioId, string $chaveSecreta): string { $payload = [ 'sub' => $usuarioId, 'iat' => time(), 'exp' => time() + 900, // expira em 15 minutos ]; return JWT::encode($payload, $chaveSecreta, 'HS256'); } function validarJwt(string $token, string $chaveSecreta): ?array { try { $decodificado = JWT::decode($token, new Key($chaveSecreta, 'HS256')); return (array) $decodificado; } catch (Exception $e) { return null; } } A grande vantagem do JWT é não depender de nenhum estado guardado no servidor: qualquer serviço que conheça a chave secreta consegue validar o token sozinho, o que facilita muito arquiteturas com vários microsserviços. Por outro lado, um JWT não pode ser "desligado" facilmente antes da hora marcada para expirar, por isso o tempo de vida costuma ser curto (minutos). Outro cuidado importante: o conteúdo do payload é apenas codificado, não criptografado, então nunca é uma boa ideia colocar dados sensíveis dentro dele.

Ler dica

Programação

Autenticação por Sessão: o alicerce dos logins tradicionais na web

Antes de tokens e APIs modernas, praticamente toda aplicação web usava sessões para manter o usuário logado. É um método que ainda funciona muito bem para sistemas tradicionais, onde as páginas são geradas pelo próprio servidor. A ideia é simples: depois que o usuário faz login, o servidor cria um registro interno (a sessão) guardando quem ele é. Em vez de repetir usuário e senha em toda requisição, o navegador recebe apenas um identificador dessa sessão, normalmente guardado em um cookie. Um exemplo típico de login com sessão em PHP: <?php session_start(); if ($_SERVER['REQUEST_METHOD'] === 'POST') { $usuario = $_POST['usuario']; $senha = $_POST['senha']; $hash = buscarHashDoUsuario($usuario); if ($hash && password_verify($senha, $hash)) { session_regenerate_id(true); $_SESSION['usuario_id'] = buscarIdDoUsuario($usuario); header('Location: /painel.php'); exit; } exit('Credenciais invalidas.'); } E, na página protegida, basta checar se a sessão existe: <?php session_start(); if (empty($_SESSION['usuario_id'])) { header('Location: /login.php'); exit; } echo "Bem-vindo de volta, usuario #{$_SESSION['usuario_id']}"; Alguns detalhes fazem toda a diferença na segurança de sessões: sempre regenerar o ID da sessão após o login (evita ataques de fixação de sessão), e configurar o cookie com as flags secure, httponly e samesite, para reduzir riscos de roubo de sessão e CSRF. O ponto fraco das sessões aparece quando o sistema cresce e passa a rodar em vários servidores ao mesmo tempo: como a sessão fica guardada na memória do servidor, é preciso compartilhar esse estado entre as instâncias, geralmente usando algo como Redis. Para aplicações que crescem para múltiplos servidores ou para APIs consumidas por aplicativos externos, tokens costumam ser uma escolha mais prática.

Ler dica

Programação

Chaves de API: o guia prático para proteger suas integrações

Se você já integrou um sistema com um gateway de pagamento, um serviço de nota fiscal eletrônica ou uma API de WhatsApp Business, provavelmente já usou uma chave de API. É um dos métodos mais comuns de autenticação entre sistemas, principalmente em integrações servidor a servidor. Uma chave de API é, na prática, uma string longa e aleatória que identifica uma conta ou aplicação. Diferente de um login tradicional, ela não representa uma pessoa específica, e sim "quem tem posse da chave". Por isso, proteger essa chave é tão importante quanto proteger uma senha. Um cuidado essencial, muitas vezes esquecido, é nunca guardar a chave em texto puro no banco de dados. O ideal é armazenar apenas o hash dela, da mesma forma que se faz com senhas: <?php // Gerando uma chave de API segura function gerarApiKey(): string { return bin2hex(random_bytes(32)); } // Validando a chave recebida em uma requisição function validarApiKey(): array { $chave = $_SERVER['HTTP_X_API_KEY'] ?? null; if (!$chave) { http_response_code(401); exit(json_encode(['erro' => 'Chave de API ausente'])); } $conta = buscarContaPorApiKeyHash(hash('sha256', $chave)); if (!$conta) { http_response_code(403); exit(json_encode(['erro' => 'Chave de API invalida'])); } return $conta; } Outro ponto prático é sempre permitir a revogação e a rotação das chaves. Se uma chave vazar (por exemplo, publicada acidentalmente em um repositório de código), o ideal é conseguir desativá-la imediatamente e gerar uma nova, sem precisar recriar toda a conta. Vale também aplicar limite de requisições (rate limiting) por chave, para reduzir o impacto de um possível uso indevido, e nunca reaproveitar a mesma chave para ambientes diferentes, como produção e testes. Chaves de API são simples de implementar e funcionam muito bem quando o objetivo é apenas identificar uma aplicação, sem necessidade de saber qual usuário específico está por trás da requisição.

Ler dica