Documentation
¶
Overview ¶
Package client is what a project consuming iam remotely imports — a thin server-to-server HTTP client for POST /api/token. It carries none of iam's own ORM/auth machinery: a consumer's binary (including its WASM edge build) never pulls in tinywasm/orm or tinywasm/rbac just to ask "who is this user and what may they do in MY project".
This client is called from the CONSUMER'S OWN SERVER, never from the browser: client_secret must never reach a WASM/JS bundle a user can inspect (see ARCHITECTURE.md §6.4/§7). The consumer's server reads the SSO cookie off the incoming request and forwards its value here — it never verifies or decodes that cookie itself, only iam can.
Index ¶
Constants ¶
const SSOCookieName = "iam_session"
SSOCookieName is the cookie iam sets after a successful login, shared across every *.velty.cl subdomain (Domain=".velty.cl", see ARCHITECTURE.md §7). A consumer reads it off its OWN incoming request (net/http-style cookie jar, or ctx.Cookie(SSOCookieName) in this ecosystem's router.Context) and passes its value to FetchAuthzToken.
Variables ¶
var ErrNoSSOSession = fmt.Err("iam", "sso", "session-required")
ErrNoSSOSession means either no SSO cookie was forwarded, or iam rejected it (expired/forged) — both collapse to "treat this caller as anonymous", never as an error worth alarming on: an expired or absent session is routine, not an attack (same principle as tinywasm/jwt's Outcome — see its docs).
Functions ¶
func ResolveUser ¶ added in v0.0.9
ResolveUser calls POST <iamBaseURL>/api/users/resolve server-to-server: finds (or creates) a user by email within iam's identity, and returns their Sub — the same id their token's Sub will carry once they log in. For a consumer that needs to grant a resource (e.g. site ownership) to someone who may never have logged in yet. Requires only clientSecret — there is no session involved (see ARCHITECTURE.md/PathUsersResolve doc in iam's routes package for why that's safe).
Types ¶
type Identity ¶ added in v0.0.8
Identity is what FetchAuthzToken resolves for the caller's session: the authorization claims (Sub/Aud/Scope) plus the profile fields iam's /api/token response carries alongside them — a consumer showing "Hola, <Name>" needs no second call.
func FetchAuthzToken ¶
FetchAuthzToken calls POST <iamBaseURL>/api/token server-to-server, forwarding ssoCookieValue (the SSO cookie's value read off the caller's own incoming request) so iam can identify the user, and clientSecret so iam knows which project is asking. Returns the project-scoped authorization claims — Aud is projectID, Scope is the user's role codes in that project (see ARCHITECTURE.md §6.1/§6.2) — plus the user's basic profile.
The claims are decoded WITHOUT verifying the HMAC signature (tinyjwt.DecodeUnverified, not Verify): this response came directly from iam over THIS SAME HTTPS call, not from an untrusted third party presenting a token later — there is nothing to gain from re-checking a signature whose secret this consumer does not, and must never, have (ARCHITECTURE.md §6.2: the HS256 secret is internal to iam). Do not change this to Verify — it would require sharing iam's secret, which is exactly the acoplamiento this design avoids.
Source Files