Security
OAuth Verify is safe only when publishable keys stay public-by-design, PKCE/state hold, redirect URIs match exactly, and /verify/validate is your trust boundary.
On this page
Publishable credentials
Credential map: API keys & credentials.
Browser vs server
- Browser: start flow, PKCE, popup/redirect, token exchange, POST token to your API.
- Server:
POST /verify/validate, map user, create session; optional server-driven start / exchange. - Browser success ≠ authorized application user.
PKCE & state
Sync vs async generation: PKCE.
Redirect URI
- Exact match against
project_callback_urlorproject_hosted_redirect_uris[]. - Mismatch →
invalid_redirect_uri. - Prefer HTTPS in production; register localhost only for development.
postMessage origin
Popup completion uses KEYRA_AUTH_SUCCESS / KEYRA_AUTH_ERROR. Accept messages only from your authOrigin (e.g. https://auth.keyra.ie). The paste script performs this check; custom code must too.
Backend validation
Deep dive: Server validation.
Storage rules
- Prefer HttpOnly, Secure session cookies (or equivalent) issued by your backend after validate.
- Minimize token lifetime in browser memory; do not log full tokens.
HTTPS & logging
- Call KEYRA over HTTPS at
https://auth.keyra.ie. - Log verification / request ids for support — never log
access_token,code_verifier, or authorization codes. - Avoid echoing raw KEYRA error bodies that may contain sensitive fragments to untrusted clients.