Referência Técnica

Como funciona a Autorização

Autorização define o que um usuário autenticado pode fazer. O Sentinel separa esse controle em dois planos: delegação de acesso via OAuth2/OIDC e controle de permissões dentro da plataforma.

O que é autorização?

Se autenticação responde "Quem é você?", autorização responde "O que você pode fazer?". São duas etapas distintas: primeiro confirmamos a identidade, depois verificamos as permissões.

Exemplo do dia a dia

Usuário faz login

Identidade confirmada (autenticação)

Acessa o sistema

Sentinel verifica suas permissões

Vê apenas seus dados

Não acessa dados de outros (autorização)

No Sentinel Identity, a autorização funciona em dois planos complementares: um para controlar quais aplicações podem agir em nome do usuário (via OAuth2/OIDC), e outro para controlar o que o usuário pode fazer dentro da plataforma (via roles e grupos).

Dois planos de autorização

Cada plano resolve um problema diferente.

Delegação de acesso

OAuth 2.0 / OpenID Connect

Controla quais aplicações podem agir em nome do usuário e quais scopes elas possuem. O Sentinel emite access tokens, ID tokens e refresh tokens seguindo os padrões OAuth 2.0 e OpenID Connect.

Controle de acesso

RBAC + Permissões granulares

Controla o que o usuário pode fazer dentro da plataforma. O Sentinel armazena e resolve permissões baseadas em roles e grupos em tempo real, com suporte a herança e hierarquia.

OAuth 2.0 e OpenID Connect

Como aplicações obtêm tokens de acesso para agir em nome dos usuários.

Fluxo Authorization Code + PKCE

1
Início: A aplicação redireciona o usuário para o Sentinel com client_id, redirect_uri, scope e code_challenge (PKCE).
2
Login: O Sentinel autentica o usuário. Após o login bem-sucedido, o servidor OAuth2 recebe a identidade confirmada e cria um consentimento.
3
Consentimento: O Sentinel apresenta (ou pula automaticamente, se configurado) a tela de consentimento com os scopes solicitados pela aplicação.
4
Código: Um authorization code de curta duração é emitido e enviado para o redirect_uri da aplicação.
5
Token: A aplicação troca o code + code_verifier (PKCE) pelo access_token, id_token e refresh_token.

Authorization Code + PKCE

Recomendado

Fluxo padrão para aplicações web e SPAs. O PKCE protege contra interceptação do código de autorização.

Client Credentials

Machine-to-Machine

Para serviços backend que precisam de tokens sem interação de usuário.

Refresh Token

Renovação

Renovação de access tokens sem exigir nova autenticação do usuário.

Introspection

Validação

Endpoint para aplicações validarem se um access token está ativo e quem ele representa.

Claims e Scopes

Scopes disponíveis

openid

Emite ID token com sub (subject). Obrigatório para OIDC.

profile

Inclui nome e claims de perfil no ID token.

email

Inclui email e email_verified.

offline_access

Emite refresh token para renovação silenciosa.

Claims do ID Token

"sub": "uuid-da-identidade",

"email": "usuario@empresa.com",

"email_verified": true,

"name": "Nome do Usuário",

"iss": "https://auth.sentinel-identity.com",

"aud": "client-id-da-app"

Controle de acesso (RBAC)

Permissões granulares baseadas em roles e grupos, com herança automática e isolamento por organização. Veja também Permissões e Grupos.

Modelo de relações

O Sentinel armazena permissões como relações entre objetos, roles e usuários. Ao atribuir um role ou grupo, essas relações são gravadas e consultadas em cada acesso para verificar se o usuário tem permissão.

// Exemplos de relações gerenciadas pelo Sentinel:

organização:acme # membro @ usuário:uuid

organização:acme # admin @ grupo:gerentes

grupo:gerentes # membro @ usuário:uuid

Roles por organização

Cada organização define seus próprios roles. Roles de uma organização não se propagam para outras — o isolamento é garantido por design.

Grupos de usuários

Usuários podem pertencer a múltiplos grupos. Grupos acumulam roles, permitindo gestão de permissões em escala sem repetir configurações individuais.

Herança de permissões

Permissões atribuídas a um grupo são automaticamente herdadas pelos membros. Uma consulta resolve todas as permissões efetivas do usuário em tempo real.

Roles globais

Organizações Enterprise podem ter administradores globais com acesso centralizado que transcende as fronteiras de organização.

Isolamento por organização

Row-Level Security

Todas as tabelas da plataforma têm isolamento por organização no banco de dados. Dados de uma organização nunca são visíveis para outra.

Contexto por request

O Sentinel extrai o contexto de organização da sessão autenticada em cada request e aplica o filtro antes de qualquer acesso ao banco.

Permissões por escopo

As permissões incluem a organização como escopo. Um admin de "Acme" não tem acesso a dados de "TechCorp" — mesmo que o token seja o mesmo usuário.

Integrando sua aplicação

Registrar um cliente OAuth2

No Admin Console em OAuth2 Clients, registre sua aplicação com o redirect_uri, scopes e grant_types necessários. O client_id e client_secret gerados são usados no fluxo de autorização.

Endpoint de descoberta OIDC

https://auth.sentinel-identity.com/.well-known/openid-configuration

Contém todos os endpoints (authorization, token, jwks_uri, userinfo) para configuração automática de clientes OIDC.

Próximas leituras

Autenticação

Fluxo de login, métodos suportados e sessões.

MFA

TOTP, WebAuthn e configuração por aplicação (AAL2).

Permissões

RBAC, policies e verificação de acesso granular.

Grupos

Organização de usuários e herança de roles.