Portal SSO

What this browser holds after signing in with Portal: the configuration the flow uses, the identity Portal returned, and the claims on the token that Portal API calls carry.

Configuration

Inlined from astro:env/client when this bundle was built. Both values are public by definition; neither is a secret.

Feature in this build yes

service.ready false

service.configured true

PUBLIC_PORTAL_URL https://dev.vibemagic.co.uk

PUBLIC_OAUTH_CLIENT_ID project-263

redirect_uri https://static-astro-site-test.vmtest.vibemagic.co.uk/oauth/callback/

response_type / PKCE code / S256

Portal profile link https://dev.vibemagic.co.uk/app/profile

redirect_uri must match a URI registered on Portal byte for byte, trailing slash included. It is built from PUBLIC_SITE_URL — the origin the Wizard registered — not from the browser's current location.

Identity returned by Portal

signed out

The user block from the token response, kept in localStorage and restored on reload. This is where the navbar gets the identity from — there is no call to a profile endpoint.

Nothing stored. Sign in to populate this.

Access token claims

Decoded in the browser, payload only — the signature is Portal's business. The token itself is never displayed: it is a credential, and aud is the part that decides what it may call.

Browser storage

Key names only. One of these holds a refresh token, which is why this page will not print a value.

No portal-sso: keys. Nothing is stored for this origin.

Actions

Sign in leaves this origin for Portal and comes back to this page. Sign out revokes the refresh token on Portal and clears local storage — it does not end the Portal session itself, which is why signing in again returns the same user without a password prompt.

Absent on purpose: no way to sign in as a different user without leaving for Portal (Portal has neither prompt=login nor an end-session endpoint), and no route guard anywhere. Signing in proves who you are; it gates nothing.