Skip to content

Services ITokenStore

Mika Berglund edited this page Dec 25, 2025 · 2 revisions

Token Store (ITokenStore)

The Token Store is responsible for persisting token containers used by Blazorade Id. It stores:

  • Identity tokens (for establishing the signed-in user in the client).
  • Access tokens per resource (for calling protected APIs).

A token store is an implementation detail behind higher-level services, primarily the Token Service and the Authentication Service.

Responsibilities

  • Persist and retrieve identity tokens.
  • Persist and retrieve access tokens keyed by a resource identifier.
  • Clear all stored tokens.

Service contract members

  • ClearAsync: Clears all stored identity and access tokens from the store.

  • GetAccessTokenAsync: Retrieves the access token container associated with the specified resource identifier, if one is stored.

  • GetIdentityTokenAsync: Retrieves the stored identity token container, if one is available.

  • SetAccessTokenAsync: Stores or removes the access token container associated with the specified resource identifier.

  • SetIdentityTokenAsync: Stores or removes the identity token container representing the signed-in user.

Usage patterns

Access tokens are stored per resource

Access tokens are stored and retrieved by providing a resource identifier. This enables the Token Service to keep separate access tokens for different APIs.

Identity tokens represent the signed-in user

The identity token is stored and retrieved without a resource identifier. The Authentication Service can use the identity token to construct a claims principal when a sign-in flow is not required.

Clearing tokens

Clearing the store is intended to remove all identity and access tokens, typically as part of a sign-out flow.

Implementations included

Token store base class

The abstract base class TokenStoreBase provides the common interface implementation surface and a consistent key naming scheme for derived stores.

Key scheme details:

  • All keys are prefixed with blazorade.id..
  • Keys are lowercased.
  • Token-type-specific keys can be extended with a suffix.

This is used by browser-based stores to compute stable keys for storage.

In-memory token store

InMemoryTokenStore stores tokens in process memory.

Characteristics:

  • Tokens are not persisted across browser sessions.
  • Access tokens are stored in a dictionary keyed by resource identifier.
  • Identity tokens are stored as a single value.

Note:

  • This implementation may remove expired tokens as an internal hygiene measure. Token validity decisions still belong to the caller.

Default behavior:

  • This is the default token store registered by Blazorade Id when no other token store is configured.
  • It provides predictable, in-memory token handling without persistence beyond the current application lifetime.

Browser local storage token store

BrowserLocalStorageTokenStore stores tokens in the browser's local storage using Blazored.LocalStorage.

Characteristics:

  • Tokens persist across browser sessions.
  • Access tokens are stored under a key derived from the token type and the resource identifier.
  • Identity tokens are stored under a key derived from the token type.
  • Clearing tokens removes all entries whose key begins with the Blazorade Id key prefix.

Browser session storage token store

BrowserSessionStorageTokenStore stores tokens in the browser's session storage using Blazored.SessionStorage.

Characteristics:

  • Tokens persist for the duration of the browser tab session.
  • Storage keys follow the same scheme as the browser local storage implementation.
  • Clearing tokens removes all entries whose key begins with the Blazorade Id key prefix.

Important contract note:

  • This implementation retrieves token containers without checking expiry on read.
  • If you rely on the Token Store contract to only return still-valid tokens, ensure the calling code validates the token container expiry, or update the store to enforce expiry consistently.

Design notes and risks

  • Token validity responsibility: The token store persists and returns token containers as-is. Callers must validate token freshness and suitability for use (for example, by checking expiry or other claims) before using a returned token.
  • Storage semantics for null: The contract allows passing null to the set methods. Implementations may either persist a null value or remove the key entirely. The provided implementations remove the entry when null is provided.
  • Token persistence choice: Local storage is long-lived and will survive browser restarts. Session storage is shorter-lived and is scoped to the tab session. Choose the store based on your threat model and user experience requirements.

References

Clone this wiki locally