angular-auth-oidc-client is an OpenID Foundation-certified Angular library for adding OpenID Connect and OAuth2 authentication to a single-page application, using the Authorization Code Flow with PKCE by default. Maintained by Damien Bowden (damienbod), it handles the parts of OIDC that are easy to get wrong by hand: the redirect dance with your identity provider, token storage, silent renewal, and session restoration across page reloads. If you need standards-based auth in an Angular app and would rather not hand-roll a protocol, this is one of the most widely used options. This guide covers how the angular oidc client works and, more importantly, how to configure it without opening security holes.
What the library does
At its core, angular-auth-oidc-client implements the client side of OpenID Connect against any compliant identity provider, Auth0, Okta, Microsoft Entra ID, Keycloak, and others. Rather than you managing authorization URLs, code exchange, and token validation, the library exposes a small surface and does the protocol work underneath.
Its default and recommended flow is the Authorization Code Flow with PKCE (Proof Key for Code Exchange). This matters for security: PKCE protects the authorization code exchange against interception, and it is the correct choice for browser-based public clients that cannot keep a client secret. The older Implicit Flow, which returned tokens directly in the URL, is discouraged in current OAuth guidance, and a library defaulting to Code Flow with PKCE is doing the right thing.
Installing and configuring
Add the library with the schematics, which scaffold the basic wiring for you:
ng add angular-auth-oidc-client
It asks a few questions about your flow and provider and generates the configuration. If you prefer to install manually:
npm i angular-auth-oidc-client
Configuration in a standalone-bootstrap app looks roughly like this:
import { provideAuth } from 'angular-auth-oidc-client';
export const appConfig = {
providers: [
provideAuth({
config: {
authority: 'https://your-idp.example.com',
redirectUrl: window.location.origin,
postLogoutRedirectUri: window.location.origin,
clientId: 'your-client-id',
scope: 'openid profile email',
responseType: 'code',
silentRenew: true,
useRefreshToken: true,
},
}),
],
};
The authority is your identity provider's issuer URL, from which the library discovers endpoints. Note responseType: 'code' (Authorization Code Flow) and the absence of any client secret, which has no place in a browser app.
The two calls you must understand
Most confusion with the angular auth oidc client comes from mixing up its two key methods, so be precise about them.
checkAuth() should be called once on every app load, typically from your root component's ngOnInit. It bootstraps the library: it processes the callback if the user has just returned from the identity provider, restores an existing session from storage so a refresh keeps the user signed in, and starts silent renewal if configured. It does not redirect anyone. Think of it as "figure out the current auth state."
authorize() should be called when the user actively initiates login, clicking a sign-in button, or when an auth guard demands authentication. It redirects the browser to the identity provider's login page. Think of it as "start a login."
export class AppComponent implements OnInit {
private oidc = inject(OidcSecurityService);
ngOnInit(): void {
this.oidc.checkAuth().subscribe(({ isAuthenticated }) => {
// session restored or callback processed; no redirect here
});
}
login(): void {
this.oidc.authorize(); // user-initiated; redirects to the IdP
}
}
Calling authorize() on every load instead of checkAuth() produces the classic redirect loop. Keep the roles straight and the flow behaves.
Securing the configuration
The library gives you a secure default, but configuration choices can still weaken it. A few things to get right.
Use refresh tokens with rotation, and mind token storage. Setting useRefreshToken: true enables silent renewal via refresh tokens rather than hidden iframes, which is the more reliable modern approach. Be aware that in a browser, tokens live in the JavaScript-accessible context, so a cross-site scripting vulnerability in your app can expose them. That makes your app's own XSS defenses part of your auth security, not a separate concern.
Request minimal scopes. Ask only for the scopes the app needs. Over-broad scopes hand the client more access than it should hold, widening the damage if a token leaks.
Validate on the server too. Client-side auth state controls what the UI shows; it is not a security boundary. Your API must independently validate the access token on every request, signature, issuer, audience, and expiry, because a browser client can be manipulated. The library authenticates the user in the SPA; it does not protect your backend for you.
Keep the library current. Auth libraries sit on the security-critical path, and this one moves at Angular's cadence, with recent major versions tracking recent Angular releases. Running an outdated version can mean missing security fixes. This is a general open-source hygiene point: an SCA tool will flag when a dependency like this one falls behind or picks up a known-vulnerable transitive package, so upgrades are driven by data rather than memory. For broader guidance on securing an SPA's auth layer, the Academy is a good next step.
FAQ
Which OAuth flow does angular-auth-oidc-client use?
By default it uses the Authorization Code Flow with PKCE, the recommended flow for browser-based public clients. PKCE protects the code exchange against interception, and it avoids the older Implicit Flow that returned tokens directly in the URL and is now discouraged.
What is the difference between checkAuth() and authorize()?
checkAuth() runs once on app load to process any callback, restore an existing session, and start silent renewal; it does not redirect. authorize() starts a user-initiated login and redirects to the identity provider. Calling authorize() on load instead of checkAuth() causes a redirect loop.
Is storing tokens in the browser safe?
Tokens in a browser are reachable by JavaScript, so a cross-site scripting flaw in your app can expose them. The library uses secure flows, but you still must defend against XSS, request minimal scopes, and prefer short-lived tokens with refresh-token renewal to limit exposure.
Does the library secure my backend API?
No. It authenticates the user within the Angular app and manages tokens client-side. Your API must independently validate every access token, its signature, issuer, audience, and expiry, on each request. Client-side auth state controls the UI, not access to your server.