Esta página conduz a integração em cinco etapas, uma de cada vez. Comece digitando seu e-mail corporativo para descobrir a configuração SAML. O BFF recebe somente o domínio normalizado; o e-mail completo nunca sai do navegador.
Pré-requisitos: instalar o pacote e preparar os clientes
Preparar PortalAuth
Browser: configure o registry e instale o pacote privado antes de inicializar o cliente.
import (
authsdk "github.com/Iniciador-de-Pagamentos/auth/sdk"
authv1pb "github.com/Iniciador-de-Pagamentos/protocol/gen/go/auth/v1"
)
// connection é o transporte gRPC autenticado do workload (mTLS + IAM do Cloud Run).
// O SDK não disca nem configura esse transporte: quem o monta é a aplicação.
sessionClient := authv1pb.NewSessionServiceClient(connection)
validator, err := authsdk.NewValidatorWithClient(sessionClient)
if err != nil { return err }
context, err := validator.Validate(ctx, sid, audience)
11. Descoberta
22. SAML
33. JWT
44. Sessão
55. Claims
1. Descoberta
concluído ✓
O que acontece: o navegador envia só o domínio do e-mail e o BFF chama GetPublicSignInConfiguration para devolver a configuração SAML do tenant.
O que esperar: a lista de provedores SAML do tenant.
O que acontece: o login vai por redirect contra o GCIP, nunca por popup.
O que esperar: uma identidade Firebase autenticada no tenant.
Aguardando descoberta…
Ver código
Browser · TypeScript
await auth.signInWithRedirect(provider.value);
// No retorno do provedor, já na carga da página:
const result = await auth.getRedirectResult();
const unsubscribe = auth.onChange((claims, user) => render(user));
3. Credencial inicial: JWT bearer do GCIP
concluído ✓
O que acontece: o BFF valida o ID token e mostra as entradas de access que ele carrega.
O que esperar: um painel com a identidade e os escopos, presets e grants efetivos do token.
As claims são um snapshot do momento de emissão. Atualize o token para receber claims reconciliados depois.
4. Credencial posterior: token bearer de sessão do authd
concluído ✓
O que acontece: o ID token é trocado por uma sessão authd (CreateSession), que depois é validada e revogada.
O que esperar: cookie __Host-auth_example HttpOnly no navegador, com o sid, e sessão validada no servidor a cada requisição.
Nesta arquitetura, o campo chamado sid pelo protocolo é o token secreto. Ele viaja só nesse cookie HttpOnly, que o JavaScript da página não lê, e expira junto com a sessão. Revogar apaga o cookie só depois de o authd confirmar.
O que acontece: o navegador decodifica access por escopo e o BFF autoriza cada rota com a tabela da aplicação e o recurso resolvido.
O que esperar: escopos, presets e grants efetivos legíveis, além de uma montagem que separa rotas públicas das rotas autenticadas.
O JWT carrega entradas [kind, scope_id, preset_id, grants]. O middleware nunca usa IDs crus da URL como verdade: a aplicação resolve o tenant, a organização ou o customer real antes de chamar can.
Claims ainda não lidos.
Use modulesOfAnyScope apenas para descoberta. Para autorizar uma rota, passe o escopo resolvido e o namespace do tenant a hasModule, hasVariant ou modulesOf.