The one way to reach any Kirak endpoint - see api.dart for the full
operation-string contract. Auth operations ("auth.login",
"auth.verify-otp", ...) are ordinary calls; token responses are adopted
into session.
A signed-in session. expiresAt is ms since epoch, computed client-side
when the tokens are adopted. user is null when the server response
carried none and the follow-up /auth/me lookup failed.
The only storage kirak ships: in-memory, cleared when the process exits.
Deliberately the ONLY default - unlike a browser (which has localStorage)
there is no single correct persistent answer outside a specific app
context (server Dart, a CLI, a Flutter app all differ). kirak_flutter
supplies a real persistent default; anything else passes its own
AuthStore via KirakAuthOptions.storage.
kirak_flutter's default AuthStore - see the design doc (spec 3.2) for
why shared_preferences, not flutter_secure_storage, is the default: it is
a widely used session-persistence choice in production Flutter apps, and
it doesn't carry flutter_secure_storage's real, current platform-specific
reliability issues. A stricter-threat-model app can still pass its own
AuthStore (backed by flutter_secure_storage or anything else) to
createKirakFlutterClient's options.auth.storage.
Handles the Apple-web-auth-token redirect
(myapp://auth/callback?token=..., or ?error=...&message=... on
failure - see kirak-core's apple_social_callback_route). Calls
api("auth.verify-web-auth", {"token": token}), which auto-adopts
through the core's existing auto-capture rule.
Creates a client and, if a persisted session exists, restores it before
returning - so a call fired immediately after this resolves already
carries the restored session. Pass KirakClientOptions.httpClient in
tests to inject a fake; production code leaves it null and gets a real
http.Client().
Same as createClient, but supplies a working, persistent default
AuthStore (SharedPreferencesAuthStore) when the caller's
KirakClientOptions.auth didn't already set one - so an unconfigured
Flutter app stays logged in across restarts with no configuration. An
explicit options.auth.storage is never overridden.
The authenticated user exactly as kirak-core returns it (snake_case wire
shape) - an open map, not a fixed class, since kirak-core's /auth/me and
login responses vary by app. token (an echoed bearer token some kirak-core
routes include) is stripped before this ever reaches a KirakSession.
A Kirak-specific error. code is any string kirak-core returns
(INVALID_API_KEY, TOKEN_EXPIRED, VALIDATION_ERROR, ...) plus a few
SDK-only codes: NETWORK_ERROR (unreachable/non-JSON response),
INVALID_SESSION and SESSION_SUPERSEDED (from adoptSession).
