Autenticação e autorização são pilares da segurança da informação. Autenticação verifica a identidade de um usuário ou sistema, enquanto autorização determina quais recursos ou ações essa identidade pode acessar. Nesta aula, exploraremos mecanismos modernos como MFA, RBAC, ABAC, OAuth e OpenID Connect, fundamentais para proteger sistemas e dados.

Entender a diferença entre autenticação e autorização é crucial: autenticação responde "quem é você?", autorização responde "o que você pode fazer?". Ambos são frequentemente implementados em conjunto, mas com tecnologias distintas.

MFA (Autenticação Multifator)

MFA (Multi-Factor Authentication) é um método de autenticação que exige dois ou mais fatores de verificação para conceder acesso. Os fatores são categorizados em algo que você sabe (senha), algo que você tem (token, smartphone) e algo que você é (biometria). O MFA reduz significativamente o risco de comprometimento, pois mesmo que uma senha seja roubada, o invasor precisa do segundo fator.

Exemplos comuns incluem: senha + código enviado por SMS, senha + aplicativo autenticador (como Google Authenticator), ou senha + impressão digital. Implementações modernas usam TOTP (Time-based One-Time Password) ou notificações push. O MFA é obrigatório em muitos padrões de segurança, como PCI-DSS e GDPR.

Exemplo de fluxo TOTP:

1. Usuário fornece senha (primeiro fator).
2. Servidor valida a senha.
3. Servidor solicita código TOTP do app autenticador.
4. Usuário gera código no app (ex: 482910).
5. Servidor verifica código usando chave secreta compartilhada.
6. Se válido, acesso concedido.

RBAC (Controle de Acesso Baseado em Papéis)

RBAC (Role-Based Access Control) é um modelo de autorização que atribui permissões a papéis (roles), e usuários recebem esses papéis. Isso simplifica o gerenciamento, pois as permissões são associadas a funções organizacionais (ex: administrador, gerente, usuário comum). Um usuário pode ter múltiplos papéis, e papéis podem herdar permissões de outros (hierarquia).

Por exemplo, em um sistema hospitalar, o papel "médico" pode acessar prontuários, enquanto "enfermeiro" pode apenas registrar sinais vitais. RBAC é amplamente usado em sistemas empresariais e é suportado por bancos de dados e frameworks como Django, Spring Security e Active Directory.

Exemplo de definição de papéis:

Papéis:
- admin: permissões totais (CRUD em todos os recursos)
- editor: permissões de leitura e escrita em artigos
- leitor: permissões de leitura em artigos

Usuário Alice: papéis [admin, editor]
Usuário Bob: papéis [leitor]

Alice pode criar, editar e deletar artigos.
Bob pode apenas visualizar artigos.

ABAC (Controle de Acesso Baseado em Atributos)

ABAC (Attribute-Based Access Control) é um modelo de autorização mais granular que usa atributos do usuário, do recurso, do ambiente e da ação para decidir o acesso. Diferente do RBAC, que depende de papéis fixos, o ABAC avalia políticas baseadas em regras lógicas (ex: "permitir acesso se usuário é gerente E departamento = vendas E horário = comercial").

Atributos comuns incluem: cargo, localização, horário, tipo de dispositivo, classificação do dado. ABAC é flexível e dinâmico, mas mais complexo de implementar. É usado em sistemas de nuvem, IoT e ambientes com requisitos de segurança elevados. O padrão XACML (eXtensible Access Control Markup Language) é uma referência para ABAC.

Exemplo de política ABAC:

Regra: Permitir acesso a documento financeiro se:
  - atributo do usuário: cargo = 'contador' OU 'CFO'
  - atributo do recurso: classificação = 'confidencial'
  - atributo de ambiente: horário entre 9h e 18h
  - atributo de ação: 'ler' OU 'baixar'

OAuth e OpenID Connect

OAuth 2.0 é um protocolo de autorização que permite que aplicativos obtenham acesso limitado a recursos de um usuário em nome dele, sem compartilhar a senha. Ele define papéis como resource owner (usuário), client (aplicativo), authorization server e resource server. O fluxo típico envolve a emissão de tokens de acesso (access tokens) que são usados para acessar APIs.

OpenID Connect (OIDC) é uma camada de autenticação construída sobre OAuth 2.0. Enquanto OAuth foca em autorização, OIDC adiciona autenticação, fornecendo um token de identidade (ID token) no formato JWT (JSON Web Token). OIDC permite que um cliente verifique a identidade do usuário e obtenha informações básicas do perfil. É amplamente usado para login social ("Login com Google", "Login com Facebook").

Exemplo de fluxo OAuth 2.0 com OIDC:

1. Usuário clica em "Login com Google" no site.
2. Site redireciona para Google (authorization server).
3. Usuário faz login e consente.
4. Google redireciona de volta ao site com um código de autorização.
5. Site troca o código por tokens (access token + id token).
6. Site usa id token para autenticar o usuário (verifica assinatura, claims).
7. Site usa access token para acessar APIs do Google (ex: Google Calendar).

Referências

Exercícios

  1. Explique a diferença entre autenticação e autorização, e dê um exemplo de cada.

    2. ✓ Resposta: Autenticação verifica a identidade (ex: login com senha). Autorização determina o que o usuário pode fazer (ex: um usuário comum pode ler, mas não editar).
  2. Descreva um cenário onde o uso de MFA é essencial e explique por quê.

    3. ✓ Resposta: Em contas bancárias online, o MFA é essencial porque mesmo que a senha seja roubada, o invasor precisa do segundo fator (ex: código SMS ou biometria) para acessar a conta, protegendo os fundos.
  3. Diferencie RBAC de ABAC, destacando vantagens e desvantagens de cada um.

    4. ✓ Resposta: RBAC usa papéis fixos, fácil de gerenciar, mas menos flexível. ABAC usa atributos dinâmicos, mais granular, porém complexo de implementar. RBAC é melhor para estruturas organizacionais estáveis; ABAC para ambientes com muitas variáveis (ex: horário, localização).
  4. Explique o papel do token de acesso (access token) no OAuth 2.0 e como ele difere do token de ID no OpenID Connect.

    5. ✓ Resposta: O access token (OAuth) autoriza acesso a recursos (ex: API). O ID token (OIDC) é um JWT que autentica o usuário, contendo claims como nome e email. O access token não carrega identidade do usuário; o ID token sim.
  5. Desenhe um fluxo simples de OAuth 2.0 com OpenID Connect, indicando as partes envolvidas e os passos principais.

    6. ✓ Resposta: Passos: 1. Usuário (resource owner) acessa client (app). 2. Client redireciona para authorization server (ex: Google). 3. Usuário autentica e consente. 4. Authorization server retorna código de autorização. 5. Client troca código por access token e ID token. 6. Client usa ID token para autenticação e access token para acessar resource server.

Boas Práticas

Ao implementar autenticação e autorização, siga estas recomendações: nunca armazene senhas em texto plano; use hashing forte (bcrypt, Argon2). Para MFA, prefira TOTP ou notificações push em vez de SMS (mais seguro). Em RBAC, evite papéis muito granulares; use herança para simplificar. Em ABAC, documente bem as políticas e evite regras conflitantes. Para OAuth/OIDC, sempre valide tokens JWT (assinatura, expiração, issuer). Use HTTPS em todas as comunicações.