Autenticação e autorização

Métodos de autenticação

O Glossia suporta dois métodos de autenticação dependendo do contexto.

Sessões do navegador

Quando você faz login pela interface web, o Glossia usa autenticação baseada em sessão. Você se autentica via um provedor de terceiros (GitHub ou GitLab) usando a Assent biblioteca. Após um login bem-sucedido, um cookie de sessão é definido e usado para solicitações subsequentes.

Tokens Bearer (OAuth 2.1)

Para acessar a API (como da CLI ou outras ferramentas), o Glossia implementa OAuth 2.1 com o fluxo de código de autenticação e PKCE. O cliente obtém um token Bearer e o inclui no Authorization cabeçalho:

Authorization: Bearer <access_token>

Fluxo OAuth 2.1

1. Registro Dinâmico de Clientes

Os clientes registram-se ao invocar POST /oauth/register com seus metadados. Isso segue RFC 7591.

{
  "client_name": "My Tool",
  "redirect_uris": ["http://localhost:8080/callback"],
  "grant_types": ["authorization_code"]
}

O servidor retorna client_id e client_secret.

2. Solicitação de autorização

O cliente redireciona o usuário para /oauth/authorize com parâmetros PKCE:

GET /oauth/authorize?response_type=code&client_id=<id>&redirect_uri=<uri>&code_challenge=<challenge>&code_challenge_method=S256&state=<state>

PKCE é obrigatório para todos os clientes. Apenas o S256 método de desafio é suportado.

3. Troca de token

Depois que o usuário aprovar, o cliente troca o código de autorização por tokens em POST /oauth/token:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=<code>&redirect_uri=<uri>&client_id=<id>&code_verifier=<verifier>

A resposta inclui um token de acesso e, opcionalmente, um token de renovação.

4. Renovação de token

Quando um token de acesso expira, use o token de renovação:

POST /oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=<token>&client_id=<id>&client_secret=<secret>

Escopos

Os escopos controlam as ações que um token pode executar. Eles seguem o object:action padrão.

Modelo de autorização

O Glossia impõe duas camadas para a REST API e o servidor MCP:

1. Verificação de escopo: o token de acesso deve incluir o requerido object:action escopo.
2. Política de nível de recurso: o usuário atual deve ser autorizado para o recurso específico via Glossia.Policy.

Escopos representam o máximo capacidade de um token. O sistema de políticas garante a real permissão para um recurso específico.

Papéis

Permissões por função

Pontos de descoberta

O Glossia publica metadados em URLs bem conhecidas padrão para que os clientes descubram endpoints automaticamente.

Metadados do Servidor de Autorização OAuth (RFC 8414)

GET /.well-known/oauth-authorization-server

Retorna o emissor, endpoints, escopos suportados, tipos de concessão e métodos de desafio de código.

Metadados de Recurso Protegido (RFC 9728)

GET /.well-known/oauth-protected-resource

Retorna o identificador do recurso, servidores de autorização, escopos suportados e métodos de bearer.

Limitação de taxa

Os endpoints OAuth são limitados por taxa por endereço IP:

Quando limitado pela taxa, o servidor retorna HTTP 429 (Muitas Requisições).