@schibsted/account-sdk-browser 5.2.7 → 6.0.0-alpha.10

package/README.md

@@ -2,334 +2,79 @@
 [![Code coverage](https://codecov.io/gh/schibsted/account-sdk-browser/branch/master/graph/badge.svg)](https://codecov.io/gh/schibsted/account-sdk-browser)
 [![Snyk](https://snyk.io/test/github/schibsted/account-sdk-browser/badge.svg?targetFile=package.json)](https://snyk.io/test/github/schibsted/account-sdk-browser)
 
-# Schibsted account SDK for browsers
+# Schibsted Account SDK for browsers
 
-Welcome! This is the home of the Schibsted account JavaScript SDK for use by any website that wishes
-to use Schibsted account to sign up and log in users. Use it to generate URLs for your site's "Log
-in" button, query the logged-in status of your users, and to check whether they have access to
-products and subscriptions, etc.
+Welcome! This is the home of the Schibsted Account JavaScript SDK for browsers. Use it to let users
+sign up and log in with Schibsted Account, read the current session, and check access to products
+and features.
 
-## Getting started
+For detailed Account SDK API documentation, check [TYPEDOC](./TYPEDOC.md).
 
-This sdk mainly communicates with a service named Session Service, which is available on brand
-domains (i.e. id.vg.no) to avoid Third-Party Cookie request.
+## Before You Start
 
-Since browsers started to block Third-Party Cookies, your top domain from local machine needs to
-match your Session Service top domain. Otherwise, the Session Service cookie will be a third-party cookie
-and will not be sent with a XHR request.
+The SDK communicates mainly with Session Service on a brand domain such as `id.vg.no`. Your website
+and Session Service domain must share the same top-level site so browser cookies are sent with XHR
+requests.
 
-The same applies to cross scheme requests. The Session Service is hosted on https and therefore you need to [run your site with HTTPS locally](https://web.dev/how-to-use-local-https/).
+For local development:
 
-For example if your `pre` domain is pre.sdk-example.com, and it uses id.pre.sdk-example.com Session Service
-domain, your local domain should be local.sdk-example.com.
+- serve your site over HTTPS, because Session Service is hosted over HTTPS
+- use a local hostname with the same top-level site as the configured Session Service domain
 
-1. Do `npm install --save @schibsted/account-sdk-browser`
-1. Use this library as you would any other npm module: `import { Identity, Monetization, Payment } from '@schibsted/account-sdk-browser'`
-   With CommonJS it is possible to `require` the modules Identity, Monetization and Payment
-   by appending `/identity`, `/monetization'` or `/payment'`.
-1. Build your site as you prefer. This library uses modern JavaScript syntax (including async/await
-   and other ES2017 and WHATWG features) by default. We recommend that you do any transpilation
-   yourself for the browser versions you need to cater to. See [this paragraph](#polyfills) for
-   info about our Babel-ified version and info about polyfills.
-1. Initiate the SDK and provide at least `clientId`, `env` and `sessionDomain`.
+For example, if your pre-production site is `pre.sdk-example.com` and uses
+`id.pre.sdk-example.com` as Session Service, use a local hostname such as
+`local.sdk-example.com`.
 
-If this is for a new site and there is no sessionDomain yet, contact
-[support](mailto:schibstedaccount@schibsted.com) to initiate the process.
+If this is a new site and you do not have a `sessionDomain` yet, contact
+[support](mailto:schibstedaccount@schibsted.com).
 
-## Migration to 5.x.x (ITP)
+## Development
 
-Follow the [migration guide](./MIGRATION.md).
-
-## Simplified login widget
-
-1. Ensure that your site has no site specific terms and conditions in the Schibsted account login flow.
-1. Define rules for when and how often the simplified login prompt should be shown to unique users on your site. How you do this is up to you, but we recommend starting with showing the prompt once per user before potentially increasing this frequency over time.
-1. Set up a function to check if users landing on your domain [is logged in](https://schibsted.github.io/account-sdk-browser/Identity.html#isLoggedIn) to your site.
-1. If the user is not logged-in to your site, call the [showSimplifiedLoginWidget](https://schibsted.github.io/account-sdk-browser/Identity.html#showSimplifiedLoginWidget) function. The `showSimplifiedLoginWidget` accepts the same params as login function (`state` is required, it might be string or async function). If the simplified login prompt is to be loaded, `showSimplifiedLoginWidget` will return `true`.
-1. Set up a way to store information about which users have been shown the simplified login prompt. How you do this is up to you, but one way is to use localStorage. Use this information to execute on the rules defined in #2.
-
-## Example project
-
-There is an example that demonstrates how the SDK can be used. The code is
-[here](https://schibsted.ghe.com/user-identity/sdk-example), and you can see it live
-[here](https://pro.sdk-example.com). You have a use-case that we haven't thought of? Ask us to add
-it by creating an [issue](https://schibsted.ghe.com/user-identity/sdk-example/issues/new).
-
-You can use that code as inspiration or just fork and play with it. The account-sdk-browser NPM
-module is used for authenticating the user with Schibsted account. Take a look at how the SDK is
-initialized.
-
-When a user wants to log in to your site, you direct them to a UI flow hosted by **Schibsted Account**.
-We authenticate the user and redirect them back to your site. This final redirect back to your site is performed in accordance with the OAuth2 specification.
-This means we pass a `code` in the query string of that redirect URI.
-You can use that `code` on your site's backend, along with your client credentials (client ID and secret), to obtain an *Access Token* (AT) and a *Refresh Token* (RT).
-You should not send the AT (and **never** the RT!) to the browser. Instead, keep them on the server side and associate them with the specific user session.
-This allows you to call Schibsted Account APIs on behalf of that user.
-
-## Events
-
-The SDK fires events on the instances when something we deem interesting is happening. For example the
-[Identity](https://schibsted.github.io/account-sdk-browser/Identity.html) class
-emits some events when the user is logged in or logged out. This SDK uses a familar interface that's
-very similar to Node's [EventEmitter](https://nodejs.org/api/events.html). The most important
-methods are `.on(eventName, listener)` (to subscribe to an event) and `.off(eventName, listener)`
-(to unsubscribe to an event).
-
-The SDK also emits global events on the `window` when a new instance is created.
-Events are emitted for:
-
-| Class        | event name              |
-| ------------ | ----------------------- |
-| Identity     | `schIdentity:ready`     |
-| Monetization | `schMonetization:ready` |
-| Payment      | `schPayment:ready`      |
-
-```js
-window.addEventListener('schIdentity:ready', e => {
-    // The event contains the initialized instance (e.detail.instance);
-}
+Install dependencies and run the standard checks:
 
+```sh
+npm ci
+npm run build
+npm test
+npm run lint
+npm run typecheck
 ```
 
-## Identity
-
-Let's start with a bit of example code:
-
-#### Example
-
-```javascript
-import { Identity } from '@schibsted/account-sdk-browser';
+## API Documentation
 
-const identity = new Identity({
-    clientId: '56e9a5d1eee0000000000000',
-    redirectUri: 'https://awesomenews.site', // ensure it's listed in selfservice
-    env: 'PRE', // Schibsted account env. A url or a special key: 'PRE', 'PRO', 'PRO_NO', 'PRO_FI' or 'PRO_DK'
-    sessionDomain: 'https://id.awesomenews.site', // client-configured session-service domain
-});
+Public API documentation is generated from TypeScript source comments with TypeDoc.
 
-async function whenSiteLoaded() {
-    const loginContainer = document.getElementById('login-container');
-    if (await identity.isLoggedIn()) {
-        const user = await identity.getUser();
-        const span = document.createElement('span');
-        span.textContent = `Hello ${user.givenName}`;
-        loginContainer.appendChild(span);
-    } else {
-        loginContainer.innerHTML = '<button class="login-button">Log in</button>';
-    }
-}
-
-function userClicksLogIn() {
-    identity.login({ state: 'some-random-string-1234-foobar-wonky-pig' });
-}
+```sh
+npm run docs:build
+npm run docs:open
 ```
 
-#### Regarding `state`
-
-This parameter is an OpenID Connect parameter (described in [this paragraph in the
-spec](http://openid.net/specs/openid-connect-core-1_0.html#rfc.section.3.1.2.1)). It's formatted as
-an opaque string. This means you can send anything that can be serialized to a string. In practice,
-we have good experience sending something like a JSON value like a base64-url-encoded value — it's
-just an easy way to avoid browsers or backends messing with special characters.
-
-But as a trivial example, if you call `Identity.login(..)` with params
-`redirectUri=https://site.com&state=article%3D1234` — then at the end of the authentication flow,
-the user will be sent back to your redirectUri, and the `state` parameter will be forwarded along
-with the auth `code` parameter.
-
-It is recommended that you provide a unique identifier as part of the state, to prevent CSRF
-attacks. For example this can be accomplished by:
-
-1. Your backend generates random token: `1234abcd`, saves it in some tokenCache, and forwards to
-   your browser frontend
-1. Your frontend calls `Identity.login` with `state = base64Urlencode({ token: '1234abcd', article:
-'1234', ... })`
-1. When auth flow completes, the user is redirected back to your site. Then, your backend sees the
-   query parameters `code` (which it can exchange for OAuth tokens for the user) and `state`
-1. Your backend can do `decodedState = base64Urldecode(query.state)` and then verify that its
-   `tokenCache.contains(decodedState.token)`. If that fails, then possibly a CSRF attack was
-   attempted. If successful, remove the token from the tokenCache so the same token can't be used
-   again, and continue to show `decodedState.article`
-
-#### Authentication methods
-
-Although Schibsted account abstracts away the details of how the users sign up or log in, it's worth
-mentioning that your end users have a few ways to log in:
-
-* Username & password: pretty self-explanatory; users register using an email address and a
-    self-chosen password
-*  Passwordless - email: here, the users enter their email address and receive a one-time code that
-    they can use to log in
-*  Multifactor authentication: first client indicates which methods should be preferred, later these
-    will be included (if fulfilled) in `AMR` claim of IDToken
-
-The default is username & password. If you wish to use one of the passwordless login methods, the
-`login()` function takes an optional parameter called `acrValues` (Authentication Context Class Reference).
-The `acrValues` parameter with multifactor authentication can take following values:
-
-*  `eid` - authentication using BankID (for DEV and PRE environments you can choose between country specific solution by specifying `eid-no` or `eid-se` instead)
-*  `otp-email` - passwordless authentication using code sent to registered email
-*  `password` - force password authentication (even if user is already logged in)
-*  `otp` - authentication using registered one time code generator (https://tools.ietf.org/html/rfc6238)
-*  `sms` - authentication using SMS code sent to phone number
-*  `password otp sms` - those authentication methods might be combined
-
-The classic way to authenticate a user, is to send them from your site to the Schibsted account
-domain, let the user authenticate there, and then have us redirect them back to your site. If you
-prefer, we also provide a popup that you can use. In this method, the authentication happens on a
-separate popup window and at the end of the auth flow. We recommend that you make the popup send a
-signal to your main page — using
-[postMessage](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or something
-similar — to indicate that the user is logged in. If the popup window fails to open, it'll
-automatically fall back to the redirect flow. The SDK Example project mentioned above demonstrates
-how it can work. Again, you can see [sdk-example](https://schibsted.ghe.com/user-identity/sdk-example) if you
-want a working example.
-
-#### Is the user logged in?
-
-Schibsted account relies on browser cookies to determine whether a user is recognized as logged in.
-The SDK provides functions that can be used to check if the user that's visiting your site is
-already a Schibsted user or not.
+During documentation work, use:
 
-*  [Identity#isLoggedIn](https://schibsted.github.io/account-sdk-browser/Identity.html#isLoggedIn)
-    tells you if the user that is visiting your site is already logged in to Schibsted account or not.
-
-*  [Identity#isConnected](https://schibsted.github.io/account-sdk-browser/Identity.html#isConnected)
-    tells you if the user is connected to your client. A user might have `isLoggedIn=true` and at the
-    same time `isConnected=false` if they have logged in to Schibsted account, but not accepted terms
-    and privacy policy for your site.
-
-If you've lately changed your terms & conditions, maybe the user still hasn't accepted them. In that
-case they are considered *not connected*. In that case, if they click "Log in" from your site, we
-will just ask them to accept those terms and redirect them right back to your site.
-
-#### Logging out
-
-If you want to log the user out of Schibsted account, you can call
-[Identity#logout](https://schibsted.github.io/account-sdk-browser/Identity.html#logout). This
-will remove the Schibsted account brand session. User will still be logged into Schibsted account.
-
-## Monetization
-
-The preferred method for checking whether a user has access to a product/subscription is
-[Monetization#hasAccess](https://schibsted.github.io/account-sdk-browser/Monetization.html#hasAccess).
-It requires using Session Service, and supports both Schibsted account productId's and Zuora
-feature id's.
-
-#### Example
-
-```javascript
-import { Monetization } from '@schibsted/account-sdk-browser';
-
-const monetization = new Monetization({
-    clientId: '56e9a5d1eee0000000000000',
-    redirectUri: 'https://awesomenews.site', // ensure it's listed in selfservice
-    sessionDomain: 'https://id.aweseome.site', // client-configured session-service domain
-    env: 'PRE', // Schibsted account env. A url or a special key: 'PRE', 'PRO' or 'PRO_NO'
-});
-
-try {
-    // Check if the user has access to a a particular product
-    const userId = await identity.getUserId();
-    const data = await monetization.hasAccess([productId], userId);
-    alert(`User has access to ${productId}? ${data.entitled}`);
-} catch (err) {
-    alert(`Could not query if the user has access to ${productId} because ${err}`);
-}
-```
-
-## Payment
-
-This class provides methods for paying with a so-called paylink, buying a product, getting links to
-pages for redeeming voucher codes, reviewing payment history, and more.
-
-#### Example
-
-```javascript
-import { Payment } from '@schibsted/account-sdk-browser';
-
-const paymentSDK = new Payment({
-    clientId: '56e9a5d1eee0000000000000',
-    redirectUri: 'https://awesomenews.site', // ensure it's listed in selfservice
-    env: 'PRE', // Schibsted account env. A url or a special key: 'PRE', 'PRO' or 'PRO_NO'
-});
-
-// Get the url to paymentSDK with paylink
-const paylink = '...';
-const paylinkUrl = paymentSDK.purchasePaylinkUrl(paylink);
-
-// Or another example --- pay with paylink in a popup
-paymentSDK.payWithPaylink(paylink);
+```sh
+npm run docs:watch
 ```
 
-## Appendix
-
-#### Polyfills
-
-This SDK uses modern JavaScript features. If you support older browsers, you should use a tool like
-babel to transform the JavaScript as needed. However, since certain teams have deployment pipelines
-where it's difficult to do their own transpilation, we do provide some opt-in es5 files as well:
+Generated docs are written to `docs/` and are not committed.
 
-1. `@schibsted/account-sdk-browser/es5`: Include both `Identity`, `Monetization` and `Payment`.
-1. `@schibsted/account-sdk-browser/es5/global`: Include both `Identity`, `Monetization` and
-   `Payment`. In addition, add them as variables to the global `window` object.
-1. `@schibsted/account-sdk-browser/es5/identity`, `@schibsted/account-sdk-browser/es5/monetization`
-   or `@schibsted/account-sdk-browser/es5/payment` can be used to only include each class by itself.
+## Example Project
 
-But then regardless of whether you use the es5 versions or not, you might need to polyfill certain
-things that might be missing in the browsers you wish to support. A quick test using IE11 showed
-that we needed polyfills for `Promise`, `URL`, `Object.entries`, `fetch`, `Number.isFinite` and
-`Number.isInteger`.
-
-#### Cookies
-
-There are some cookies used by Schibsted account. They should all be considered opaque on the
-browser side. Nevertheless, here is a short description of them.
-
-1. The **autologin** cookie (often called 'the remember-me-cookie'): The cookie name in the
-   production environments is `vgs_email`, because reasons (on PRE, it is called `spid-pre-data`).
-   It's a JSON string that's encoded using the standard `encodeURIComponent()` function and is an
-   object that contains two pieces of information that's important:
-    * `remember`: if set to `true`, the user chose to be remembered and this means we usually support
-      auto-login (that is, if you call the Schibsted account hassession service, and no session can
-      be found in the session database, it will automatically create a new one for the user so that
-      they don't have to authenticate again. If it is `false`, it should be interpreted as the user
-      does not want to be automatically logged in to any site when their session expires
-    * `v`: the version number
-1. The **session** cookies: Cookie names in production environments are `identity`, and `SPID_SE` or
-   `SPID_NO`. It contains:
-    * `user`: an object (if it's missing, a call to hassession will return a `401` with a
-      `UserException` that says `No session found`)
-        * `userId` identifies the user. We use this property to compare "old" user with "new" user and
-          fire events that indicate that the user has changed
-        * `is_logged_in` indicates if the user is logged in
-    * `user_tags`: a map that contains some flags about the user; namely:
-        * `is_logged_in` indicates if the user is logged in (this seems to be a duplicate of a
-          property with a similar name in the parent `user` object)
-        * `terms`: a map of term ids that indicate if they've been accepted by the user.
-    * `referer` (yep, missing the double "rr"..): If this is missing, a call to hassession will
-      return a `401` with a `UserException` that says `No session found`.
+The internal example integration is available in the
+[sdk-example repository](https://schibsted.ghe.com/user-identity/sdk-example).
 
 ## Publishing
 
-Versioning and changelog are handled by [Release Please (GitHub Action)](https://github.com/googleapis/release-please). Publishing to [npmjs.org](https://www.npmjs.com/package/@schibsted/account-sdk-browser) is handled by the [npm-publish workflow](./.github/workflows/npm-publish.yml). See the [Release Please workflow](./.github/workflows/release-please.yml) and [`release-please-config.json`](./release-please-config.json).
+Versioning and changelog updates are handled by
+[Release Please](https://github.com/googleapis/release-please). The release configuration lives in
+[`release-please-config.json`](./release-please-config.json), and publishing to
+[npmjs.org](https://www.npmjs.com/package/@schibsted/account-sdk-browser) is handled by the
+[npm-publish workflow](./.github/workflows/npm-publish.yml) when a GitHub Release is published.
 
-When publishable changes have been merged to `master`, Release Please will create (or update) a release pull request.
-The suggested version is based on the commit messages in accordance with the [Conventional Commits](https://www.conventionalcommits.org/) specification — `fix:` bumps the patch version, `feat:` bumps the minor version, and `feat!:` or a `BREAKING CHANGE:` footer bumps the major version.
-Other prefixes (`chore:`, `docs:`, `test:`, `refactor:`, `ci:`, `build:`, `style:`) do not trigger a release and are hidden from the changelog.
+Use [Conventional Commits](https://www.conventionalcommits.org/) for changes that should be picked
+up by release automation.
 
-To release/publish the changes simply merge the corresponding pull request and wait for the publish workflow to finish.
-Release-please will create a git tag (e.g. `v5.2.7`) and a GitHub Release, and the [publish workflow](./.github/workflows/npm-publish.yml) will push the package to npmjs.org.
-
-
-## LICENSE
+## License
 
 Copyright (c) 2026 Schibsted Products & Technology AS
 
-Licensed under the [MIT
-License](https://schibsted.ghe.com/user-identity/account-sdk-browser/blob/master/LICENSE.md)
-
-Unless required by applicable law or agreed to in writing, software distributed under the License is
-distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
-implied. See the License for the specific language governing permissions and limitations under the
-License.
+Licensed under the [MIT License](./LICENSE.md).

package/dist/account-sdk.d.ts

@@ -0,0 +1,22 @@
+import { Account } from './account.js';
+import { AccountConfig } from './types/account.js';
+/**
+ * Creates and registers the single Account SDK instance for the current browser window.
+ *
+ * The created instance is stored on `window.schAccount` and the SDK emits
+ * `schAccount:ready` with the instance in `event.detail.instance`.
+ *
+ * @param config - Client, redirect, environment, and Session Service configuration.
+ * @throws {SDKError} If the SDK cannot run in the current browser context, if an Account instance
+ * has already been initialized, or if configuration validation fails.
+ * @group Core API
+ */
+export declare function createAccountSdk(config: AccountConfig): Account;
+/**
+ * Resolves the Account SDK instance registered by `createAccountSdk()`.
+ *
+ * If the instance already exists, the promise resolves immediately. Otherwise it waits for
+ * `schAccount:ready` and rejects if initialization does not happen within the SDK timeout.
+ * @group Core API
+ */
+export declare function getAccountSdk(): Promise<Account>;

package/dist/account.d.ts

@@ -0,0 +1,179 @@
+import { AccountConfig, AccountEventListener, AccountEventName } from './types/account.js';
+import { LoginOptions, SimplifiedLoginData, SimplifiedLoginWidgetLoginOptions, SimplifiedLoginWidgetOptions } from './types/login.js';
+import { HasAccessResult } from './types/monetization.js';
+import { ConnectedSessionResponse, SessionResponse, SessionUserId } from './types/session.js';
+/**
+ * Unified client-side interface for a configured Schibsted Account integration.
+ *
+ * Create an instance with `createAccountSdk()` unless you explicitly need to construct it
+ * yourself. The instance coordinates identity, login, session, and access-check features for one
+ * configured client.
+ *
+ * @group Core API
+ */
+export declare class Account {
+    #private;
+    constructor(config: AccountConfig);
+    /**
+     * Queries Session Service and returns the current browser session state.
+     *
+     * This call may trigger a full-page session refresh redirect. Configure
+     * `callbackBeforeRedirect` if your app needs to persist state before that navigation.
+     *
+     * @throws {SDKError} If the Session Service call fails.
+     */
+    hasSession(): Promise<SessionResponse>;
+    /**
+     * Checks whether the browser currently has a Schibsted Account session.
+     *
+     * Returns `false` instead of throwing when the session lookup fails.
+     */
+    isLoggedIn(): Promise<boolean>;
+    /**
+     * Checks whether the current user is connected to the configured client.
+     *
+     * A user can be logged in to Schibsted Account without being connected to your client, for
+     * example before accepting required terms.
+     */
+    isConnected(): Promise<boolean>;
+    /**
+     * Returns the connected user session data.
+     *
+     * @throws {SDKError} If the user is not connected to the configured client.
+     */
+    getUser(): Promise<ConnectedSessionResponse>;
+    /**
+     * Returns the realm-specific Schibsted Account user id as a number.
+     *
+     * Use `getUserUuid()` when you need the globally unique user id.
+     *
+     * @throws {SDKError} If the user is not connected to the configured client.
+     */
+    getUserId(): Promise<number>;
+    /**
+     * Returns an external identifier for the authenticated user, scoped to the configured client
+     * and external party.
+     *
+     * @param externalParty - External party for which the identifier is generated.
+     * @param optionalSuffix - Optional suffix included when generating the identifier.
+     * @throws {SDKError} If the session lookup fails, the session does not contain a `pairId`, or
+     * `externalParty` is empty.
+     * @deprecated Retained for compatibility with existing integrations. Avoid new usage.
+     */
+    getExternalId(externalParty: string, optionalSuffix?: string): Promise<string>;
+    /**
+     * Returns the globally unique user id from the current session.
+     *
+     * @throws {SDKError} If the user is not connected to the configured client.
+     */
+    getUserUuid(): Promise<string>;
+    /**
+     * Returns the user SDRN from the current session.
+     *
+     * @throws {SDKError} If the SDRN is missing from the session response.
+     */
+    getUserSDRN(): Promise<string>;
+    /**
+     * Returns minimal user context for simplified login prompts.
+     *
+     * Returns `null` if the global account session cannot be read.
+     */
+    getUserContextData(): Promise<SimplifiedLoginData | null>;
+    /**
+     * Returns the Varnish `sp_id` value from the current session when present.
+     */
+    getSpId(): Promise<string | null>;
+    /**
+     * Starts the login flow with either a full-page redirect or a popup.
+     *
+     * Call this from a user gesture when `preferPopup` is enabled, otherwise browser popup blockers
+     * may block the popup and the SDK will fall back to redirect navigation.
+     *
+     * @param options - Login URL parameters.
+     * @returns A popup window reference when a popup is opened; otherwise `null`.
+     */
+    login(options: LoginOptions): Window | null;
+    /**
+     * Logs the user out from the brand Session Service session and redirects the browser.
+     *
+     * @param redirectUri - Where Session Service should redirect the browser after logout.
+     */
+    logout(redirectUri?: string): void;
+    /**
+     * Builds the login URL without navigating the browser.
+     *
+     * @param options - Login URL parameters.
+     */
+    loginUrl(options: LoginOptions): string;
+    /**
+     * Builds the logout URL without navigating the browser.
+     *
+     * @param redirectUri - Where Session Service should redirect the browser after logout.
+     */
+    logoutUrl(redirectUri?: string): string;
+    /**
+     * Builds the Schibsted Account profile page URL.
+     *
+     * @param redirectUri - Where the account page should redirect the browser afterwards.
+     */
+    accountUrl(redirectUri?: string): string;
+    /**
+     * Loads and displays the simplified login widget when user context is available.
+     *
+     * Your application decides how often to call this method. The `state` field in `loginParams`
+     * may be a string or a function that resolves to a string.
+     * Widget open and cancel events can be observed with `on()`.
+     *
+     * @returns `true` when the widget was displayed.
+     * @throws {SDKError} If user context data is missing or the widget script cannot be loaded.
+     */
+    showSimplifiedLoginWidget(loginParams: SimplifiedLoginWidgetLoginOptions, options?: SimplifiedLoginWidgetOptions): Promise<boolean>;
+    /**
+     * Enables or disables caching for subsequent session lookups.
+     *
+     * Changing this setting does not remove an existing cached session.
+     */
+    setSessionCachingEnabled(enabled: boolean): void;
+    /**
+     * Removes the cached Session Service user session response.
+     */
+    clearCachedUserSession(): void;
+    /**
+     * Checks whether the current user has access to any of the requested products or features.
+     *
+     * When `productIds` is omitted, the ids configured as `defaultProductIds` are used.
+     * Results are cached according to the TTL returned by Session Service.
+     *
+     * @param productIds - Product or feature ids to check instead of the configured defaults.
+     * @returns Access data, or `null` when the user is not entitled.
+     * @throws {SDKError} If product ids are not provided or configured, `sessionDomain` is missing,
+     * the current user cannot be resolved, input is invalid, or the request fails.
+     */
+    hasAccess(productIds?: string[] | undefined): Promise<HasAccessResult | null>;
+    /**
+     * Removes a cached access-check result.
+     *
+     * @param productIds - Product or feature ids used for the cached lookup.
+     * @param userId - User id used for the cached lookup.
+     */
+    clearCachedAccessResult(productIds: string[], userId: SessionUserId): void;
+    /**
+     * Subscribes to Account events.
+     *
+     * Supported event names are defined by {@link AccountEventName}.
+     *
+     * @param event - Event name.
+     * @param listener - Listener that receives an `Event` or `CustomEvent`.
+     */
+    on<EventName extends AccountEventName>(event: EventName, listener: AccountEventListener<EventName>): this;
+    /**
+     * Unsubscribes from Account events.
+     *
+     * Supported event names are defined by {@link AccountEventName}.
+     *
+     * @param event - Event name.
+     * @param listener - Listener to remove.
+     */
+    off<EventName extends AccountEventName>(event: EventName, listener: AccountEventListener<EventName>): this;
+}
+export default Account;

package/dist/cache.d.ts

@@ -0,0 +1,65 @@
+/**
+ * Cache implementation used when web storage is available. Wraps a `Storage` instance.
+ * @private
+ */
+declare class WebStorageCache {
+    store: Storage;
+    get: (key: string) => string | null;
+    set: (key: string, value: string) => void;
+    delete: (key: string) => void;
+    /**
+     * Create web storage cache object
+     * @param store - A reference to either `sessionStorage` or `localStorage` from a
+     * `Window` object
+     */
+    constructor(store: Storage);
+}
+/**
+ * Cache implementation used when web storage is not available. Stores entries in an in-memory object.
+ * @private
+ */
+declare class LiteralCache {
+    store: Record<string, string>;
+    get: (key: string) => string | undefined;
+    set: (key: string, value: string) => void;
+    delete: (key: string) => void;
+    /**
+     * Create JS object literal cache object
+     */
+    constructor();
+}
+/**
+ * Cache class that attempts WebStorage (session/local storage), and falls back to JS object literal
+ * @private
+ */
+export default class Cache {
+    cache: WebStorageCache | LiteralCache;
+    type: string;
+    /**
+     * @param storeProvider - A function to return a WebStorage instance (either
+     * `sessionStorage` or `localStorage` from a `Window` object)
+     * @throws {SDKError} - If sessionStorage or localStorage are not accessible
+     */
+    constructor(storeProvider?: () => Storage);
+    /**
+     * Get a value from cache (checks that the object has not expired)
+     * @param key
+     * @private
+     */
+    get(key: string): unknown;
+    /**
+     * Set a cache entry
+     * @param key
+     * @param value
+     * @param expiresIn - Value in milliseconds until the entry expires
+     * @private
+     */
+    set(key: string, value: unknown, expiresIn?: number): void;
+    /**
+     * Delete a cache entry
+     * @param key
+     * @private
+     */
+    delete(key: string): void;
+}
+export {};