oidc-client-ts dropped the implicit grant on purpose

A fork that exists because the original stopped

The lineage explains the API. This project is a fork of IdentityModel/oidc-client-js, which halted development in June 2021. It was ported to TypeScript with a similar API for the initial 2.0 release, so code written against the old library generally reads the same, but it is a different package name and a different maintainer group.

The stated policy going forward is that the library will focus only on protocols that retain support in OAuth 2.1. That single sentence is the most important design fact here, and it has a concrete consequence: the implicit grant is not supported by this client. Anyone migrating from oidc-client-js with an implicit flow configured will find that code path gone rather than deprecated.

Scope is browser only. The description names client side, browser based JavaScript applications, plus user session and access token management. There is no Node or server side client in this package.

The five protocol flows it implements

The README lists five supported flows, each with its own document under docs/protocols/. Authorization Code Grant with PKCE is first, which tells you where the project stands. Authorization Code Grant is listed separately as a distinct document, so both the plain code flow and the PKCE variant are first class. Resource Owner Password Credentials Grant is also supported. Refresh Token Grant is there, and so is Silent Refresh Token in iframe Flow, the mechanism for getting a new token without a visible redirect.

All of this sits on top of OpenID Connect Core 1.0. The package therefore handles both the OAuth2 half (authorisation, tokens, refresh) and the OIDC half (identity claims, id token, discovery).

The runtime dependency list is short. The single production dependency is jwt-decode at version 4 or later, which is used to read claims out of tokens. Everything else in package.json is a development dependency: Vitest for tests, eslint with the TypeScript and stylistic plugins, api-extractor for the published type surface, typedoc for documentation, esbuild for bundling, fake-indexeddb for tests, husky for git hooks and jose for test token handling. A dependency tree of one runtime package is a genuine advantage for something shipped into every page load of a SPA.

Installing the package and building from source

Consumption is a single npm install:

$ npm install oidc-client-ts --save

The published version is 3.5.0, matching the tag released on 2026-03-13. The package ships only dist, and the exports map offers an ESM build at./dist/esm/oidc-client-ts.js, a UMD build at./dist/umd/oidc-client-ts.js, and types at./dist/types/oidc-client-ts.d.ts, so bundler, CommonJS require and type resolution each take a defined path rather than whatever the bundler guesses.

Working on the library itself is a four step sequence:

$ git clone https://github.com/authts/oidc-client-ts.git
$ cd oidc-client-ts
$ npm install
$ npm run build

npm test runs a TypeScript compile followed by vitest run, which means a type error fails the suite before any test executes. npm run build runs a build script and then build-types, where tsc emits declarations and api-extractor processes the published type declarations. Linting is eslint with --max-warnings=0 and a cache.

Running the Parcel sample and the separate Angular app

The repository ships one sample in tree, a Parcel project, and points at a second sample hosted elsewhere:

$ cd samples/Parcel
$ npm install
$ npm run start

The dev server then answers on http://localhost:1234, which is where you exercise the redirect flow end to end against a real provider. The Angular integration is a separate repository, authts/sample-angular-oidc-client-ts, linked rather than included, so expect to fetch it separately if your stack is Angular.

That sample arrangement is thin. One in-tree Parcel sample plus an external Angular repo is not much to copy from, and the API documentation lives on the project page at authts.github.io/oidc-client-ts, generated by typedoc from typedoc.json rather than written by hand. Migration guidance from the old library is a single file, docs/migration.md. If you are porting existing oidc-client-js code, that file is the first thing to read, not the protocol pages.

What the release history implies about upgrading

The version list is unusual enough to read carefully: v3.5.0 on 2026-03-13, v2.5.0 on 2026-01-05, then v3.4.1 on 2025-11-17. A 2.x tag landing between two 3.x tags means the 2.x line received maintenance releases after 3.x shipped, so pinning to a major version is not equivalent to freezing your dependencies. Anyone who stayed on 2.x to keep a stable API was still receiving fixes.

The last push was on 2026-09-01, so work continues on the main branch between releases rather than only at tag time.

Licensing is Apache-2.0, stated in both the README and the package.json license field, which is the permissive choice that matters most for a library embedded in a front end bundle. The LICENSE file at the repository root is the text to read if your organisation requires it, and api-extractor's presence means the public API surface is tracked deliberately, so a major version bump reflects considered changes rather than accidental export drift.

Where this client is the wrong choice

Three cases. Implicit grant deployments are out, stated plainly by the README. Server side confidential clients are out, because a browser library keeps a client secret and token in the page, which is the wrong trust boundary regardless of what the provider allows. And a team with no appetite for OAuth plumbing should look elsewhere entirely: this library gives you protocol machinery, not a login screen.

There is a subtler failure mode around silent refresh. The iframe flow depends on a third party cookie surviving in the browser, and browser privacy settings increasingly do not guarantee that. The README documents the flow without stating what happens when the cookie is blocked, so the behaviour your users get in a locked down browser is something you must determine in the sample app rather than from the docs.

The real alternative is the platform's own tooling: a hosted identity provider's JavaScript SDK, or the Web Crypto plus a hand rolled authorization code exchange. A vendor SDK ties you to one provider's session model and its own configuration shape but removes the protocol maintenance. Hand rolling the exchange with PKCE removes the dependency entirely but leaves you owning discovery document parsing, id token validation, state and nonce storage, and refresh scheduling, which is exactly the list of things this package exists to implement.

Editorial conclusion

Pick oidc-client-ts when you are building a browser SPA against an authorization code plus PKCE server and want typed token and session management without writing the plumbing. Do not pick it for an implicit grant deployment, since the client removed that flow, and do not pick it for a confidential backend client, since a browser library is the wrong trust model there. Before shipping, read docs/migration.md if your old code targets oidc-client-js, and confirm the silent refresh iframe flow works against your provider, since it depends on a third party cookie surviving modern browser policy.

Frequently asked questions

Official sources

1. authts/oidc-client-ts on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases