angular-auth-oidc-client handles the OIDC redirect that Angular apps usually get wrong

checkAuth() is what turns the redirect into a session

The single most important line of guidance in the README is easy to skim past. After configuring the library, you call the method checkAuth() from your app.component.ts. The method is needed to process the redirect from your Security Token Service and set the correct states, and it must be used to ensure the correct functioning of the library.

That is the whole architecture in one sentence. When a user signs in, the identity provider redirects back to your application with the authorization code in the URL. Nothing about your session exists until something reads that code, exchanges it for tokens and validates the result. checkAuth() is that something.

The call returns a LoginResponse, and the sample destructures the fields you actually need.

this.oidcSecurityService.checkAuth().subscribe((loginResponse: LoginResponse) => {
  const { isAuthenticated, userData, accessToken, idToken, configId } = loginResponse;

  /*...*/
});

The service is injected, and authorize() and logoff() sit next to checkAuth() as the other two entry points you will call. logoff() returns an observable, and the sample subscribes to it and logs the result.

The practical consequence for an application is ordering. If a component reads the access token before checkAuth() has completed, the token is not there yet, and the symptom is a page that loads half-authenticated rather than a clear error. That is why the README places the call in ngOnInit of the root component, and it is why a guard that redirects to the provider should not be the first thing that runs.

The documentation site carries a Samples section with code samples for most of the common use cases, and the README points there for anything beyond the code flow example.

ng add detects standalone and NgModule applications

The library supports schematics via ng add, and the schematic does real work rather than dropping a file you have to move yourself.

ng add angular-auth-oidc-client

After the questions, the schematic detects how your application is bootstrapped and configures the library accordingly. For standalone applications, which bootstrap with bootstrapApplication, an auth.config.ts is created and provideAuth(authConfig) is added to the providers of your application config. For NgModule applications, an AuthConfigModule is created and imported in your AppModule.

You can override the detection explicitly, and the two flags are mutually exclusive.

ng add angular-auth-oidc-client --standalone
ng add angular-auth-oidc-client --legacy-modules

There is a subtlety in the standalone case. The README says --standalone also works in NgModule applications, in which case provideAuth(authConfig) is added to the providers of the AppModule. The --legacy-modules option requires an AppModule, so the two options cannot be combined. In other words, standalone here describes the configuration style rather than the application type, and the legacy path is the one that is actually restricted.

The plain npm route is equally short, and the README gives both package managers.

npm install angular-auth-oidc-client

yarn add angular-auth-oidc-client

Whichever route you take, the note in the quickstart applies: if you installed with the schematics, the modules and files described below are already in place.

The config object decides the flow, and silent renew has a companion warning

The configuration object is where the protocol choices are made, and the quickstart example is compact enough to read as a checklist. In the NgModule style the library is registered with AuthModule.forRoot and a config block.

AuthModule.forRoot({
  config: {
    authority: '<your authority address here>',
    redirectUrl: window.location.origin,
    postLogoutRedirectUri: window.location.origin,
    clientId: '<your clientId>',
    scope: 'openid profile email offline_access',
    responseType: 'code',
    silentRenew: true,
    useRefreshToken: true,
    logLevel: LogLevel.Debug,
  },
})

Three settings define the shape of the flow. responseType set to code selects the authorization code flow rather than the implicit one. silentRenew with useRefreshToken turns on background renewal of the session, and the scope list includes offline_access, which the README says is the default recommendation when the two are used together, since the refresh token is what makes the silent renewal possible.

Some providers support refresh token renewal in the browser without offline_access, and in those cases the README says you can suppress the configuration warning with disableRefreshTokenOfflineAccessScopeWarning: true. That option exists because a mismatch between the requested scope and the provider's behaviour is a common source of confusing failures, and the library would otherwise warn on every startup.

The logLevel with LogLevel.Debug is what you would use while setting up. The README also mentions that the library provides event callbacks and the OidcSecurityService for the rest of the API, and the access token is read with getAccessToken(), which returns an observable.

const token = this.oidcSecurityService.getAccessToken().subscribe(...);

The interceptor covers secure routes, and the feature list is broader than the config

Attaching a token to outgoing requests is the part most teams get wrong by hand, and the library offers a built-in interceptor for it. The README says you can use the built in interceptor to add the access tokens to your request, and the configuration carries a secureRoutes setting that lists the URLs it applies to. The setting is a list of URLs under secureRoutes inside the config.

The manual alternative is documented too, using HttpHeaders with a Bearer prefix.

import { HttpHeaders } from '@angular/common/http';

const token = this.oidcSecurityServices.getAccessToken().subscribe((token) => {
  const httpOptions = {
    headers: new HttpHeaders({
      Authorization: 'Bearer ' + token,
    }),
  };
});

The feature list is broader than the quickstart config suggests, and that breadth is the reason to read it. The library supports OpenID Connect Code Flow with PKCE, Code Flow PKCE with Refresh tokens, OpenID Connect Implicit Flow, OpenID Connect Session Management 1.0, RFC7009 for OAuth 2.0 Token Revocation, RFC7636 for Proof Key for Code Exchange, and the OAuth 2.0 Pushed authorisation requests draft. It also supports authentication using redirect or popup, and it states that it implements OIDC validation as specified, with complete client side validation for REQUIRED features.

That last claim is the one to test against your own threat model, because implicit flow is listed as supported, and implicit flow is the older model where the token comes back in the URL fragment. Having it available for a legacy provider is a compatibility feature, not a recommendation.

OpenID Foundation certification covers RP Implicit and Config RP

The acknowledgements section states that the library is certified by the OpenID Foundation, and the certification mark in the README names the profiles: RP Implicit and Config RP. That is a specific claim with a specific scope, and it is worth reading as such.

RP means relying party, which is what your Angular application is, and the two certified profiles are the implicit flow relying party and the configuration relying party. A certification against a published conformance suite is a meaningful statement about interoperability, because the suite is run against the implementation rather than asserted in prose. It is not a statement about every deployment concern, and the certification is attached to the library rather than to your configuration of it.

The certification also tells you what the maintainers prioritise. The library is aimed at real identity providers rather than at a toy, and the feature list names modern OIDC providers as supported, with the samples section offering code for the common cases. The homepage is the npm package page, and the documentation lives on angular-auth-oidc-client.com, with a samples section and a docs folder in the repository that contains the site source.

For a procurement conversation, the certification is the artefact to point at, and the scope line to point at alongside it. The README also claims support for all modern OIDC identity providers, which is a claim about breadth rather than something the certification covers, and it is the claim you would test with your own provider.

The repository is a full Angular workspace with its own release pipeline

The project is an Angular workspace rather than a single library folder, and the package.json scripts show the whole pipeline. The library itself lives under projects/, and the build goes through ng build with a development and a production configuration, with a copy-files step for the schematics assets. Publishing runs a production build, builds the schematics, and then npm pack followed by npm publish into the dist directory, and there is a separate next tag for the prerelease channel.

Tests are split into two suites. test-lib runs the unit tests with coverage, test-lib-ci does the same with the watch flag off, and test-integration runs a separate integration-tests project. The repository has a vitest-base.config.ts at the root, which is where the test runner configuration lives, and the eslint config, prettier settings, a lefthook.yml for commit hooks and a license-banner.txt that is presumably stamped into source files.

Release management is handled with semantic releases and GitHub Actions, and there is a CHANGELOG.md plus a SECURITY.md at the root, which is the disclosure route for anyone who finds a problem in the token handling.

The version numbering gives a good sense of the pace. The package is at 22.0.1, and the recent releases are 22.0.1 on 2026-09-27, 22.0.0 on 2026-08-15 and 21.0.3 on 2026-08-09. Two releases inside two months is a fast pace, and it is a signal to read the changelog before every bump rather than to let a major update land on a dependency update.

MIT licensing, and the samples are the real documentation

The licence is MIT, and the repository has a LICENSE file at the root alongside the license-banner.txt used by the build. You can use, modify and redistribute the code, including in commercial and closed-source applications, provided the copyright notice and the licence text are retained. That is a licensing fact rather than legal advice, and for a library sitting in the dependency tree of a product it is one of the simpler cases.

The documentation strategy is worth understanding, because it determines how you will actually use the library. The README is a summary, the site at angular-auth-oidc-client.com holds the reference documentation, and the Samples section carries code samples for most of the common use cases. The repository carries a docs/ directory that contains the site source, and the package.json even has a start-docs script that runs the documentation site locally.

The samples are not decoration. The package scripts include a build-all-samples step that runs a script over the sample projects, and a start script that serves a specific sample named sample-code-flow-refresh-tokens with SSL enabled. The sample apps live in the projects/ area and are built as real Angular applications, which is why a certs/ directory exists in the repository. The code flow with refresh tokens sample is the one the start script points at, and it is the closest thing to a working reference for the configuration described earlier.

The core repository, projects/angular-auth-oidc-client, is what the prettier check covers, and the tools/ directory holds the helper scripts such as the blockwords check and the sample build script.

Editorial conclusion

angular-auth-oidc-client fits an Angular team that needs standards-compliant OIDC in a browser application, with a certified implementation and a schematic that wires the configuration for you. It does not fit a project that intends to hand-roll the flow, since the validation rules it implements for REQUIRED features are the part most worth not reimplementing. Before adopting it, run ng add angular-auth-oidc-client and read the generated auth.config.ts, confirm your provider issues refresh tokens and honours the offline_access scope, and wire checkAuth() into application startup before anything else calls the service.

Frequently asked questions

Official sources

1. damienbod/angular-auth-oidc-client on GitHub
2. License: MIT
3. Project website
4. README
5. Releases