Fecha o Bloco D (APIs e integrações). Foco: você propõe como Team Studio se autentica na infra do cliente corporativo sem fazer ele criar usuário separado, e responde questões de CISO sobre identity management com substância.

Pré-requisito: Semana 8 (REST/APIs). Tempo estimado: 4 horas de leitura + 1 hora de exercício. Output prático: você responde "como vocês se autenticam no nosso AD?" sem improvisar.

Por que essa semana importa

Empresa de 50+ funcionários quase sempre tem SSO corporativo (Single Sign-On). Funcionário não cria conta em cada sistema; loga uma vez no Active Directory (ou Okta, ou Google Workspace) e todos os sistemas reconhecem.

Quando Team Studio for proposto pra essa empresa, primeira pergunta de TI:

"Como vocês integram com nosso SSO? Suportam SAML? OAuth com nosso IdP?"

Resposta errada: "Vocês criam um usuário pra Team Studio." Resposta correta: "Suportamos SAML 2.0 e OAuth 2.0 com OIDC. Qual seu identity provider? Posso configurar SCIM pra provisionamento automático?"

Sem repertório, você vira fornecedor que cria conta solta na empresa do cliente. Cada conta solta = mais um ponto de risco de segurança. CISO vai recusar.

Bônus: agentes do Team Studio também precisam autenticar em APIs do cliente. Saber gerenciar credenciais de forma segura (Vault, secrets manager) é parte do contrato.

1. O modelo mental: identidade vs autenticação vs autorização

Três conceitos que parecem iguais mas são diferentes:

1.1 Identidade (Identity)

Quem você é. Geralmente identificado por email, username, ou identificador único.

Exemplo: ana@empresa.com

1.2 Autenticação (Authentication, AuthN)

Provar que você é quem diz ser. Geralmente via: - Algo que você SABE (senha) - Algo que você TEM (dispositivo, smart card, app TOTP) - Algo que você É (biometria)

MFA combina 2+ desses.

1.3 Autorização (Authorization, AuthZ)

O que você PODE FAZER depois de autenticado. Define permissões.

Exemplo: - Ana é Manager (autorização) - Manager pode acessar relatórios financeiros (permissão) - Manager NÃO pode deletar usuários (permissão negada)

1.4 IdP (Identity Provider) vs SP (Service Provider)

  • IdP: sistema que VERIFICA identidade. Tem o "banco de usuários". Exemplos: Active Directory, Okta, Auth0, Google Workspace.
  • SP: sistema que RECEBE usuário autenticado e dá acesso. Exemplos: Salesforce, Jira, Team Studio.

SSO funciona porque SP confia no IdP. "Se Okta diz que Ana é Ana, eu acredito."

2. OAuth 2.0 - o padrão moderno

OAuth 2.0 (RFC 6749, 2012) é protocolo de autorização (não autenticação, embora seja usado pra isso na prática). Permite que app A acesse recurso em app B sem ver a senha do usuário.

2.1 Os 4 papéis

  1. Resource Owner (titular): o usuário
  2. Resource Server: API que tem o recurso (Gmail API, Spotify API)
  3. Client: app que quer acessar recurso (sua app, Team Studio)
  4. Authorization Server: sistema que gera tokens (Google, Auth0)

2.2 Fluxo Authorization Code (mais comum)

1. Usuário em app A clica "Login com Google"

2. App A redireciona pra Google com:
   - client_id (identidade do app A)
   - redirect_uri (pra onde Google volta)
   - scope (o que app A quer: email, calendar, etc)
   - state (CSRF token)

3. Google mostra tela "App A quer acessar seu email. Permitir?"

4. Usuário aprova.

5. Google redireciona pra app A com um CODE (curto, single-use)

6. App A (backend) troca CODE por TOKEN:
   POST https://oauth.google.com/token
   - code (do passo 5)
   - client_id, client_secret (autentica app A)

7. Google retorna access_token (e refresh_token)

8. App A usa access_token pra chamar API do Google:
   GET https://api.google.com/me
   Authorization: Bearer eyJhbGc...

9. Google valida token, retorna dados.

2.3 PKCE (Proof Key for Code Exchange)

OAuth original tem problema: client_secret precisa ficar no backend. Apps mobile e SPAs não têm "backend seguro".

PKCE (pronuncia "pixie") resolve isso: - App gera código aleatório code_verifier no início - Calcula hash code_challenge = SHA256(code_verifier) - Manda code_challenge na etapa 2 - No passo 6, envia code_verifier (não secret) - Server valida que SHA256(verifier) == challenge

Resultado: app pode trocar code por token sem ter client_secret.

Padrão moderno (2025): OAuth 2.0 com PKCE pra TODOS os tipos de cliente. Substitui flows antigos (Implicit, Password) que eram inseguros.

2.4 Access token vs Refresh token

  • Access token: vida curta (15 min a 1h). Usado pra chamar API.
  • Refresh token: vida longa (dias a meses). Usado pra pegar novo access token quando expira.

Por que: se atacante roubar access token, ele expira rápido. Se roubar refresh token, server pode invalidar.

2.5 Scopes

Define o que o app pode fazer. Granular.

Exemplos Google: - email - só email - profile - perfil básico - calendar.readonly - ler calendário (não escrever) - calendar - ler e escrever calendário - drive.file - só arquivos criados pelo app

Princípio do menor privilégio: peça SÓ o scope que precisa. Cliente avalia o que aceita.

3. OpenID Connect (OIDC)

OAuth 2.0 é AUTORIZAÇÃO. Pra usar pra LOGIN (autenticação), você precisa de extensão: OIDC.

OIDC adiciona ao OAuth: - ID Token: JWT que contém dados do usuário (email, name, sub) - UserInfo endpoint: pode buscar mais dados depois - Discovery: /.well-known/openid-configuration lista todos os endpoints

OIDC + OAuth 2.0 com PKCE = padrão moderno de SSO via APIs.

Provedores OIDC populares: - Google (login com Google) - Microsoft (Azure AD / Entra ID) - Okta - Auth0 - Keycloak (self-hosted, open source)

4. SAML 2.0 - o padrão enterprise

SAML (Security Assertion Markup Language) é protocolo XML mais antigo (2005), DOMINANTE em enterprise tradicional.

4.1 Como funciona

Similar ao OAuth conceitualmente, mas: - Usa XML (não JSON) - Mais verboso (assertions de 5-10KB) - Permite Identity Provider iniciar (SP-initiated vs IdP-initiated) - Foi pensado pra ambientes corporativos pesados

4.2 Por que ainda existe

SAML é OBRIGATÓRIO em integração com Active Directory Federation Services (ADFS), muitos sistemas legados, governo, finanças.

Empresa que tem Microsoft AD on-prem: SAML é prioridade. Empresa cloud-native moderna: OIDC é prioridade.

4.3 Como ele funciona em alto nível

1. Usuário tenta acessar Team Studio
2. Team Studio (SP) redireciona pra IdP (ADFS)
3. IdP autentica usuário (com ou sem login se já logado)
4. IdP gera SAML Assertion (XML assinado)
5. Browser POSTs Assertion pra Team Studio
6. Team Studio valida assinatura, extrai email, libera acesso

4.4 Trust establishment

Antes de funcionar, IdP e SP trocam METADATA (arquivo XML com chaves públicas, URLs). Uma vez configurado, SP "confia" no IdP via assinatura digital.

4.5 Quando ofereçer SAML vs OIDC

Pra Team Studio em empresa: - Pequena/média moderna: ofereça OIDC primeiro - Grande, enterprise, banco/seguro: ofereça SAML - Cliente exige: dá pra ter os dois (Auth0, Okta suportam ambos)

5. SSO em detalhe

Single Sign-On: usuário loga UMA VEZ, acessa todos os sistemas conectados.

5.1 Modelos de SSO

Hub-and-spoke: IdP central, cada SP integra com ele.

        [Okta IdP]
        /    |    \
   [Slack][Jira][Salesforce]

Mais comum em empresas modernas.

Federation: múltiplos IdPs confiam entre si.

Mais comum em governo, parcerias entre empresas.

5.2 Identity Providers populares

Okta: líder de mercado, ~$8-15/usuário/mês. Microsoft Entra ID (antigo Azure AD): inclusos no Microsoft 365. Google Workspace: inclui SSO básico. Auth0 (Okta): mais focado em developer experience. Keycloak: open source, self-hosted. OneLogin, JumpCloud: alternativas menores.

5.3 SCIM - provisionamento automático

SCIM (System for Cross-domain Identity Management) é protocolo pra IdP CRIAR/ATUALIZAR/DELETAR contas no SP automaticamente.

Sem SCIM: novo funcionário entra → IT cria conta no Okta + Slack + Jira + Salesforce + Team Studio (5 sistemas). Vai sair → IT precisa lembrar de deletar em todos.

Com SCIM: IT cria no Okta, Okta sincroniza com todos os outros. Sai = automaticamente desativa todos.

Sinal de Team Studio enterprise-ready: oferece SAML/OIDC + SCIM.

5.4 Just-in-Time (JIT) provisioning

Alternativa simples ao SCIM: quando usuário tenta logar pela primeira vez via SSO, SP cria conta automaticamente baseado no SAML/OIDC assertion.

Mais simples, menos completo (não revoga quando usuário sai do IdP).

6. JWT (JSON Web Tokens)

JWT é formato de TOKEN usado em quase todos os protocolos modernos (OAuth, OIDC, sessões).

6.1 Anatomia

JWT é string com 3 partes separadas por ponto:

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1MTIzIiwiZXhwIjoxNzE2NjI1ODAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Decodificando (base64):

Header:

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload (claims):

{
  "sub": "u123",
  "name": "Ana Silva",
  "exp": 1716625800,
  "iat": 1716622200
}

Signature: HMAC(header + payload, secret_key)

6.2 Claims padrão

  • sub: subject (ID do usuário)
  • iss: issuer (quem emitiu)
  • aud: audience (pra quem é)
  • exp: expiration time (timestamp)
  • iat: issued at
  • nbf: not before (não usar antes de)

6.3 Como validar

  1. Verificar assinatura com chave pública do issuer
  2. Verificar que não expirou (exp > agora)
  3. Verificar audience (aud == você)
  4. Verificar issuer (iss == quem você confia)

6.4 JWT vs sessão server-side

JWT: stateless. Token contém tudo. Server não precisa armazenar nada. - Pros: escala fácil, microservices - Cons: difícil revogar (precisa lista de revogados ou expiração curta)

Session ID + Redis: token é só ID. Server consulta Redis pra dados. - Pros: fácil revogar, mudar permissões - Cons: depende de Redis disponível

Padrão moderno: JWT pra access tokens (curta vida) + refresh tokens com sessão server-side.

6.5 Armadilhas comuns

  • "alg: none": ATAQUE clássico onde atacante manda header "alg": "none" esperando que server aceite. Libraries antigas tinham bug. Hoje todas validam.
  • Algoritmo errado: server espera HS256 mas valida com RS256 (ou vice-versa). Bug sutil que cria vulnerabilidade.
  • Secret fraco: HS256 com secret "password123" = quebrado em segundos por brute force.
  • JWT em localStorage: vulnerável a XSS. Use httpOnly cookies pra session tokens.

7. Secrets management

Toda integração com APIs externas requer credentials (API keys, OAuth tokens, certificates). Onde guardar?

7.1 O caos típico

Times pequenos: - .env files com keys hardcoded - Compartilhados via Slack/email/notion - Commitados acidentalmente no Git (bot scanning encontra em minutos) - Sem rotação (mesma key por anos) - Mesma key em todos os ambientes (dev, staging, prod)

Isso é absurdamente comum. Ataques de cadeia de suprimentos frequentemente exploram exatamente isso.

7.2 Padrão profissional

Vault (HashiCorp): líder open source. Centraliza secrets, controla acesso, audit log, rotação automática.

AWS Secrets Manager / Azure Key Vault / GCP Secret Manager: alternativas cloud-managed.

Doppler / 1Password Secrets: alternativas SaaS modernas, mais simples.

Sealed Secrets / SOPS: secrets encriptados em Git (controverso mas válido pra ambientes específicos).

7.3 Boas práticas

Princípio do menor privilégio: cada serviço acessa SÓ os secrets que precisa.

Rotação periódica: API keys rotacionadas a cada 90 dias. Senhas humanas a cada 12 meses (alguns dizem nunca, debate).

Audit log: quem leu qual secret, quando.

Diferentes secrets por ambiente: dev key ≠ staging key ≠ prod key.

Bring Your Own Key (BYOK): cliente enterprise quer trazer as próprias chaves de encriptação. Possível mas complexo.

Pergunta de reunião:

"Como vocês gerenciam secrets? Vault, cloud secret manager, ou ainda em .env files?"

Resposta revela maturidade.

8. Como Team Studio se autentica

Quando Team Studio vai operar em empresa corporativa, há várias dimensões de autenticação:

8.1 Usuários humanos acessando Team Studio

Painel admin do Team Studio. Quem pode entrar?

Pequenas empresas: email + senha + MFA. Simples.

Empresas com SSO: Team Studio integra via SAML/OIDC com Okta/Azure AD/Google. Funcionário não cria conta separada.

Implementação: Auth0/Clerk/Supabase Auth fazem o pesado.

8.2 Agentes Team Studio acessando APIs do cliente

Agentes precisam autenticar em APIs do cliente (CRM, ERP, etc).

Opções: 1. API key estática: cliente gera key pra Team Studio. Simples mas precisa rotacionar. 2. OAuth machine-to-machine (Client Credentials Grant): Team Studio é app registrado no IdP do cliente, autentica com client_id + client_secret. 3. mTLS (mutual TLS): Team Studio tem certificado emitido pelo cliente, server verifica certificado. Mais seguro, mais complexo. 4. Service account: cliente cria "usuário robô" no sistema dele, Team Studio usa credenciais desse usuário.

Padrão emergente: OAuth Client Credentials. Boa segurança, suportado por todo provedor moderno.

8.3 Usuário final do cliente conversando com agente

Cliente final via WhatsApp não precisa autenticar (Meta já autenticou). Mas Team Studio precisa SABER quem está mandando mensagem pra puxar dados certos.

Solução: número de telefone → lookup no CRM do cliente → identifica usuário.

Edge case: número não bate com nenhum cliente. Agente trata como anônimo, pede identificação.

9. Cinco perguntas que destravam reunião sobre autenticação

9.1 "Vocês têm SSO corporativo? Qual IdP (Okta, Azure AD, Google)?"

Por que importa: define se Team Studio precisa suportar SAML, OIDC, ou ambos.

9.2 "Suportam SCIM para provisionamento automático? Ou JIT é aceitável?"

Por que importa: enterprise grande exige SCIM. Médio aceita JIT. Pequeno não liga.

9.3 "Como nossos agentes vão autenticar nas APIs de vocês? OAuth client credentials, API key, ou outro?"

Por que importa: define modelo de credencial. Cliente maduro tem preferência clara.

9.4 "Onde Team Studio armazena os secrets que vocês compartilharem? Tem Vault?"

Por que importa: cliente vai querer saber. Resposta "em .env" = perde a venda.

9.5 "Qual a política de rotação de credenciais? Rotacionamos quando?"

Por que importa: revela compliance. SOC 2 / ISO exige rotação periódica.

10. Exercício prático

Cenário: cliente Team Studio em discovery. Empresa de saúde (R$ 80M ARR), 200 funcionários, 4000 clientes finais (clínicas). Diz:

"Usamos Microsoft Entra ID pra SSO interno. Nossos clientes têm portais próprios, com login deles. Queremos que Team Studio implante agentes que conversam com pacientes via WhatsApp sobre exames e agendamentos. Como vamos organizar autenticação?"

Pratique: 1. Liste 5 perguntas pra mapear todos os tipos de autenticação envolvidos 2. Identifique 3 desafios específicos de autenticação em healthcare (LGPD, dados sensíveis) 3. Proponha arquitetura clara de quem autentica como 4. Identifique 1 oportunidade adicional pra Team Studio dentro disso

(Sugestões no fim.)

11. Material extra

Leitura essencial: - OAuth 2.0 Simplified (https://www.oauth.com/) - leitura em 1h, clara - "Auth0 Identity 101" series - gratuito, excelente - RFC 6749 (OAuth 2.0), RFC 7519 (JWT) - quando quiser ir fundo

Ferramentas para experimentar: - jwt.io (decodificar JWT visualmente) - Auth0 free tier (testar SSO sem custo) - Keycloak local (Docker) - IdP open source pra brincar

Vídeos: - "OAuth 2.0 Explained" (vários canais, 15-30 min) - "OAuth vs OIDC vs SAML" - busca, várias palestras boas

Hands-on (3 horas): - Configure "Login com Google" numa app Node.js (passport.js facilita) - Implemente endpoint que valida JWT - Brincadeira opcional: instale Keycloak via Docker, configure realm + cliente, faça flow OIDC completo

12. Sugestões pro exercício prático (veja só depois de tentar)

5 perguntas pra mapear autenticação:

  1. "Funcionários da empresa que vão administrar Team Studio: precisam logar via SSO Entra ID?"
  2. "As 4000 clínicas têm sistema próprio. Team Studio precisa acessar dado delas? Como autenticamos por clínica? OAuth, API key por clínica, ou outro?"
  3. "Pacientes via WhatsApp: como verificamos identidade? Número de celular cadastrado é suficiente ou precisa fator adicional (data de nascimento, CPF)?"
  4. "Dados de saúde têm requisito LGPD específico (categoria sensível). Como vocês tratam isso na autenticação? Consentimento explícito por interação?"
  5. "Há histórico de tentativas de invasão de paciente fingindo ser outro? Como vocês detectam impersonação no chat?"

3 desafios específicos:

  1. Dados sensíveis de saúde: LGPD art. 11 - dado sensível exige consentimento específico ou hipóteses legais restritas. Cada interação do agente precisa estar coberta.
  2. Identidade do paciente: número WhatsApp pode mudar, ser de familiar. Agente precisa confirmar identidade antes de revelar dado clínico.
  3. Multi-tenant complexo: 4000 clínicas, cada uma controlando seus dados. Team Studio precisa GARANTIR que dado do paciente da clínica A nunca chegue na clínica B.

Arquitetura proposta:

[Funcionários internos da empresa de saúde]
  ↓ login via Entra ID SSO
[Team Studio admin panel]

[4000 clínicas]
  ↓ OAuth client credentials (cada clínica tem client_id próprio)
[API da empresa de saúde] → [Team Studio]

[Paciente via WhatsApp]
  ↓ telefone identifica clínica + paciente
[Team Studio agente]
  ↓ valida consentimento LGPD no primeiro contato
  ↓ se sensível: pede confirmação adicional (data nascimento)
  ↓ chama API da clínica com OAuth client credentials
[Resposta clínica]
  ↓
[Paciente]

Oportunidade adicional:

Agente "consent manager": gerencia consentimentos LGPD por paciente, por interação, por categoria de dado. Cada vez que agente vai acessar dado sensível, valida consentimento. Se não tem, pede ANTES de revelar. Gera audit log automático pra compliance. Setup: 4-5 semanas. Valor: vira diferencial em healthtech, onde compliance é fundamental.

13. Próxima semana

Esta semana fecha o Bloco D (APIs e Integrações). O Bloco E (Segurança e Compliance) começa em seguida:

  • Semana 10: Segurança corporativa profunda - Zero Trust em detalhe, IAM avançado (RBAC/ABAC/PBAC), OWASP Top 10 com exemplos reais, threat modeling STRIDE, pentest, SAST/DAST/SCA, supply chain attacks
  • Semana 11: LGPD/GDPR avançado, SOC 2, ISO 27001 e auditoria de cliente grande - fecha o Bloco E

Depois disso, o Bloco F (Arquitetura e Comercial) finaliza a trilha com arquitetura de software, métricas/SLA, pricing/TCO, reuniões com TI e vendor lock-in.