RBAC que sabe onde se aplica
Controle de acesso baseado em papéis, com as partes que SaaS multi-tenant realmente precisa: papéis agrupam escopos, e grants aplicam eles a um recurso por vez
Roles and permissions
Roles bundle scopes, and a grant applies one inside a context.
Scopes granted by admin
await nulvless.auth.verify({
resource: "proj_16tbwq34",
roles: ["admin"],
})
O modelo
Quatro peças que se compõem, em vez de uma tabela de permissões que você mantém na mão
Access token claims
What your services read straight out of the token.
{
"sub": "usr_4c81f0a2",
"iss": "https://acme.nulvless.co",
"email": "[email protected]",
"roles": ["owner"],
"scopes": ["projects:write", "members:invite"],
"org": "org_2f19ac",
"plan": "premium"
}Claims são calculadas por token, então mudar um papel chega no próximo token emitido — não no seu próximo deploy
Escopos
A menor unidade: uma única coisa que pode ser feita
Papéis
Um conjunto nomeado de escopos que você muda sem tocar em usuários
Contextos
Organização, projeto ou qualquer recurso seu — o "onde" um papel se aplica
Grants
Um usuário com um papel em um contexto, com trilha de auditoria atrás
Escopos
A capacidade que o seu código verifica, então renomear um papel não quebra nada
Verificando
Uma chamada, no edge, com a resposta já ao lado da sessão que perguntou
verify()
Recurso e papéis entram, uma decisão tipada sai — sem policy engine para rodar
Claims no access token
Coloque papéis, escopos e claims seus no token que seus serviços já leem
Verificação no servidor
Uma service key e headers do usuário encaminhados para o que seu backend faz
Negado por padrão
Nada é alcançável até um grant dizer que é
Explorer
One trail across auth, functions, notifications and system events.
select ts, email, reason, ip from auth_events where event = "signin" and ok = false
| ts | reason | ip | |
|---|---|---|---|
| 12:04:11 | [email protected] | bad_password | 31.22.8.4 |
| 12:03:52 | [email protected] | user_banned | 77.14.2.90 |
| 12:02:19 | [email protected] | mfa_required | 81.3.44.7 |
| 11:59:03 | [email protected] | bad_password | 31.22.8.4 |
Mudanças de grant são consultáveis como qualquer outra coisa, que costuma ser o que um auditor realmente pede
Delegando
Os fluxos de convite e associação que todo produto B2B acaba construindo duas vezes
Ciclo de vida do convite
- criado
- e-mail enviado, ainda sem conta
- aceito
- grant emitido dentro do contexto alvo
- expirado
- depois da janela que você definir
- revogado
- tokens que o carregam param de passar
Convites
Convide por e-mail para um contexto e um papel, antes de existir conta
Transferência de posse
Mova o grant de owner sem abrir um ticket de suporte
Delegação
Deixe um admin conceder apenas o que ele mesmo tem
Revogação
Remova um grant e os tokens que o carregam param de passar
Convide para um contexto, não para o app
Grants são emitidos contra uma organização, um projeto ou um recurso — então a mesma pessoa pode ser owner em um lugar e leitora em outro.
import { createServerClient, forwardUserHeaders } from "@nulvless/nulvless-js";
const nulvless = createServerClient(url, "sk-…");
const { data, error } = await nulvless.auth.grants.invite(
{ email: "[email protected]", context: "org", roles: ["admin"] },
{ headers: forwardUserHeaders(req) },
);Uma plataforma, desde o primeiro usuário
Foque no seu produto. A infraestrutura de identidade é com a gente
O que você teria construído
Seis áreas, e cada uma delas é um projeto por si só.
- Autenticaçãosenhas, provedores, MFA, sessões
- AutorizaçãoRBAC, escopos, grants por recurso
- OAuth serverdiscovery OIDC, JWKS, PKCE
- Edge functionsruntime Deno, deploys, rollback
- Notificaçõestemplates, provedores, logs de entrega
- Observabilidademonitoramento, auditoria, consulta