Top Related Projects
OpenID Connect and OAuth 2.0 Framework for ASP.NET Core
Flexible and versatile OAuth 2.0/OpenID Connect stack for .NET
npm package for OpenID Connect, OAuth Code Flow with PKCE, Refresh tokens, Implicit Flow
OpenID Connect (OIDC) and OAuth2 protocol support for browser-based JavaScript applications
Quick Overview
Angular-oauth2-oidc is a library for implementing OAuth 2.0 and OpenID Connect (OIDC) in Angular applications. It provides a robust solution for authentication and authorization, supporting various grant types and token management.
Pros
- Easy integration with Angular applications
- Supports multiple OAuth 2.0 flows (Authorization Code, Implicit, Resource Owner Password Credentials)
- Automatic token refresh and storage
- Customizable and extensible
Cons
- Limited to Angular framework
- Requires understanding of OAuth 2.0 and OIDC concepts
- May have a learning curve for developers new to OAuth 2.0
- Documentation could be more comprehensive for advanced use cases
Code Examples
- Basic configuration:
import { AuthConfig } from 'angular-oauth2-oidc';
export const authConfig: AuthConfig = {
issuer: 'https://idp.example.com',
clientId: 'your-client-id',
redirectUri: window.location.origin + '/index.html',
scope: 'openid profile email'
};
- Initializing the OAuth service:
import { OAuthService } from 'angular-oauth2-oidc';
constructor(private oauthService: OAuthService) {
this.oauthService.configure(authConfig);
this.oauthService.loadDiscoveryDocumentAndTryLogin();
}
- Checking authentication status:
import { OAuthService } from 'angular-oauth2-oidc';
isLoggedIn(): boolean {
return this.oauthService.hasValidAccessToken();
}
Getting Started
-
Install the library:
npm install angular-oauth2-oidc
-
Import the
OAuthModule
in yourapp.module.ts
:import { OAuthModule } from 'angular-oauth2-oidc'; @NgModule({ imports: [ // ... OAuthModule.forRoot() ], // ... }) export class AppModule { }
-
Configure the OAuth service in your
app.component.ts
:import { OAuthService } from 'angular-oauth2-oidc'; import { authConfig } from './auth.config'; export class AppComponent { constructor(private oauthService: OAuthService) { this.oauthService.configure(authConfig); this.oauthService.loadDiscoveryDocumentAndTryLogin(); } }
-
Use the OAuth service in your components to handle authentication and token management.
Competitor Comparisons
OpenID Connect and OAuth 2.0 Framework for ASP.NET Core
Pros of IdentityServer4
- Comprehensive server-side identity solution for .NET applications
- Supports a wide range of authentication protocols and flows
- Highly customizable and extensible for complex identity scenarios
Cons of IdentityServer4
- Steeper learning curve due to its extensive feature set
- Requires more setup and configuration compared to client-side solutions
- May be overkill for simple authentication needs in single-page applications
Code Comparison
IdentityServer4 (server-side configuration):
services.AddIdentityServer()
.AddInMemoryClients(Config.Clients)
.AddInMemoryApiResources(Config.ApiResources)
.AddInMemoryIdentityResources(Config.IdentityResources)
.AddTestUsers(Config.TestUsers);
angular-oauth2-oidc (client-side configuration):
OAuthModule.forRoot({
resourceServer: {
allowedUrls: ['https://api.example.com'],
sendAccessToken: true
}
})
IdentityServer4 provides a robust server-side identity solution with extensive customization options, while angular-oauth2-oidc offers a simpler client-side approach for Angular applications. The choice between them depends on the specific requirements of your project, such as the need for a full-fledged identity server versus a lightweight client-side authentication solution.
Flexible and versatile OAuth 2.0/OpenID Connect stack for .NET
Pros of OpenIddict
- Comprehensive server-side implementation for ASP.NET Core
- Supports various flows including authorization code, implicit, and client credentials
- Highly customizable with extensive documentation
Cons of OpenIddict
- Primarily focused on server-side implementation, less suitable for client-side applications
- Steeper learning curve due to its extensive features and configuration options
Code Comparison
OpenIddict (server-side configuration):
services.AddOpenIddict()
.AddCore(options => { /* ... */ })
.AddServer(options => {
options.SetAuthorizationEndpointUris("/connect/authorize")
.SetTokenEndpointUris("/connect/token");
// Additional configuration...
})
.AddValidation();
angular-oauth2-oidc (client-side configuration):
import { AuthConfig } from 'angular-oauth2-oidc';
export const authConfig: AuthConfig = {
issuer: 'https://idp.example.com',
redirectUri: window.location.origin + '/index.html',
clientId: 'spa-client',
scope: 'openid profile email api'
};
OpenIddict is more suited for building OAuth 2.0 and OpenID Connect servers, while angular-oauth2-oidc is designed for client-side implementations in Angular applications. The choice between them depends on whether you're building a server or a client application.
npm package for OpenID Connect, OAuth Code Flow with PKCE, Refresh tokens, Implicit Flow
Pros of angular-auth-oidc-client
- More comprehensive documentation and examples
- Better TypeScript support and type definitions
- Regular updates and active maintenance
Cons of angular-auth-oidc-client
- Slightly more complex API compared to angular-oauth2-oidc
- May have a steeper learning curve for beginners
Code Comparison
angular-auth-oidc-client:
import { OidcSecurityService } from 'angular-auth-oidc-client';
constructor(public oidcSecurityService: OidcSecurityService) {}
this.oidcSecurityService.checkAuth().subscribe(({ isAuthenticated }) => {
console.log('app authenticated', isAuthenticated);
});
angular-oauth2-oidc:
import { OAuthService } from 'angular-oauth2-oidc';
constructor(private oauthService: OAuthService) {}
this.oauthService.loadDiscoveryDocumentAndTryLogin().then(() => {
if (this.oauthService.hasValidAccessToken()) {
// User is authenticated
}
});
Both libraries provide similar functionality for implementing OAuth2 and OpenID Connect in Angular applications. angular-auth-oidc-client offers more comprehensive documentation and better TypeScript support, which can be beneficial for larger projects or teams. However, it may have a slightly steeper learning curve compared to angular-oauth2-oidc.
angular-oauth2-oidc has a simpler API, which can be advantageous for smaller projects or developers new to OAuth2/OIDC. The code comparison shows that both libraries have similar usage patterns, with angular-auth-oidc-client using a more observable-based approach.
Ultimately, the choice between the two libraries depends on project requirements, team expertise, and personal preference.
OpenID Connect (OIDC) and OAuth2 protocol support for browser-based JavaScript applications
Pros of oidc-client-ts
- Framework-agnostic, can be used with any JavaScript framework
- Smaller bundle size, potentially better performance
- More active development and frequent updates
Cons of oidc-client-ts
- Less Angular-specific features and integrations
- May require more manual configuration for Angular projects
- Steeper learning curve for developers familiar with Angular ecosystem
Code Comparison
oidc-client-ts:
import { UserManager } from "oidc-client-ts";
const userManager = new UserManager(settings);
const user = await userManager.signinRedirect();
angular-oauth2-oidc:
import { OAuthService } from 'angular-oauth2-oidc';
constructor(private oauthService: OAuthService) {
this.oauthService.initLoginFlow();
}
Summary
oidc-client-ts offers a more flexible, framework-agnostic approach to OIDC implementation, with potential performance benefits. However, it may require more setup and configuration for Angular projects compared to angular-oauth2-oidc, which provides tighter integration with the Angular ecosystem. The choice between the two depends on project requirements, team expertise, and the specific Angular version being used.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
angular-oauth2-oidc
Support for OAuth 2 and OpenId Connect (OIDC) in Angular. Already prepared for the upcoming OAuth 2.1.
Credits
- jsrsasign for validating token signature and for hashing
- Identity Server for testing with an .NET/.NET Core Backend
- Keycloak (Redhat) for testing with Java
- Auth0
Resources
- Sources and Sample: https://github.com/manfredsteyer/angular-oauth2-oidc
- Source Code Documentation: https://manfredsteyer.github.io/angular-oauth2-oidc/docs
- Community-provided sample implementation: https://github.com/jeroenheijmans/sample-angular-oauth2-oidc-with-auth-guards/
Tested Environment
Successfully tested with Angular 4.3 to Angular 16 and its Router, PathLocationStrategy as well as HashLocationStrategy and CommonJS-Bundling via webpack.
At server side we've used IdentityServer (.NET / .NET Core), Redhat's Keycloak (Java), and Auth0 (Auth0 is officially supported since version 10 of this lib). For Auth0, please have a look into the respective documentation page here.
For using this library with Azure Active Directory (Azure AD), we recommend an additional look to this blog post and the example linked at the end of this blog post.
Also, the Okta community created some guidelines on how to use this lib with Okta. See the links at the end of this page for more information.
Angular 17: Use 17.x versions of this library (should also work with older Angular versions!).
Angular 16: Use 16.x versions of this library (should also work with older Angular versions!).
Angular 15: Use 15.x versions of this library (should also work with older Angular versions!).
Angular 14: Use 14.x versions of this library (should also work with older Angular versions!).
Angular 13: Use 13.x versions of this library (should also work with older Angular versions!).
Angular 12: Use 12.x versions of this library (should also work with older Angular versions!).
Angular 11: Use 10.x versions of this library (should also work with older Angular versions!).
Angular 10: Use 10.x versions of this library (should also work with older Angular versions!).
Angular 9: Use 9.x versions of this library (should also work with older Angular versions!).
Angular 8: Use 8.x versions of this library.
Angular 7: Use 7.x versions of this library.
Angular 6: Use Version 4.x of this library. Version 4.x was tested with Angular 6. You can also try the newer version 5.x of this library which has a much smaller bundle size.
Angular 5.x or 4.3: If you need support for Angular < 6 (4.3 to 5.x) you can download the former version 3.1.4 (npm i angular-oauth2-oidc@^3 --save).
Release Cycle
- We plan one major release for each Angular version
- Will contain new features
- Will contain bug fixes and PRs
- Critical bugfixes on demand
Contributions
-
Feel free to file pull requests
-
The issues contain some ideas for PRs and enhancements (see labels)
-
If you want to contribute to the docs, you can do so in the
docs-src
folder. Make sure you updatesummary.json
as well. Then generate the docs with the following commands:npm install -g @compodoc/compodoc npm run docs
Features
- Logging in via Code Flow + PKCE
- Hence, you are safe for the upcoming OAuth 2.1
- Logging in via Implicit Flow (where a user is redirected to Identity Provider)
- "Logging in" via Password Flow (where a user enters their password into the client)
- Token Refresh for all supported flows
- Automatically refreshing a token when/some time before it expires
- Querying Userinfo Endpoint
- Querying Discovery Document to ease configuration
- Validating claims of the id_token regarding the specs
- Hook for further custom validations
- Single-Sign-Out by redirecting to the auth-server's logout-endpoint
- Tested with all modern browsers and IE
- Token Revocation according to RFC 7009
Sample-Auth-Server
You can use the OIDC-Sample-Server used in our examples. It assumes, that your Web-App runs on http://localhost:4200
Username/Password:
- max/geheim
- bob/bob
- alice/alice
clientIds:
- spa (Code Flow + PKCE)
- implicit (implicit flow)
redirectUris:
- localhost:[4200-4202]
- localhost:[4200-4202]/index.html
- localhost:[4200-4202]/silent-refresh.html
Installing
npm i angular-oauth2-oidc --save
Option 1: Standalone APIs
If you use Standalone Components introduced with Angular 14, you can use our standalone API (call to provideOAuthClient
) in your main.ts
to setup the OAuthClient
:
// main.ts -- Angular 15+ version
import { bootstrapApplication } from '@angular/platform-browser';
import { provideHttpClient } from '@angular/common/http';
import { AppComponent } from './app/app.component';
import { provideOAuthClient } from 'angular-oauth2-oidc';
bootstrapApplication(AppComponent, {
providers: [
provideHttpClient(),
provideOAuthClient()
]
});
As Angular 14 does have Standalone Components but no Standalone API for its HttpClient
, you need to go with the traditional HttpClientModule
in this version:
// main.ts -- Angular 14 version
import { bootstrapApplication } from '@angular/platform-browser';
import { HttpClientModule } from '@angular/common/http';
import { AppComponent } from './app/app.component';
import { provideOAuthClient } from 'angular-oauth2-oidc';
import { importProvidersFrom } from '@angular/core';
bootstrapApplication(AppComponent, {
providers: [
importProvidersFrom(HttpClientModule),
provideOAuthClient()
]
});
The provideOAuthClient
function takes the same parameters as the forRoot function of the OAuthModule that is still in place for the sake of compatibility with existing code bases.
Option 2: Using NgModules
import { HttpClientModule } from '@angular/common/http';
import { OAuthModule } from 'angular-oauth2-oidc';
// etc.
@NgModule({
imports: [
// etc.
HttpClientModule,
OAuthModule.forRoot()
],
declarations: [
AppComponent,
HomeComponent,
// etc.
],
bootstrap: [
AppComponent
]
})
export class AppModule {
}
Logging in
Since Version 8, this library supports code flow and PKCE to align with the current draft of the OAuth 2.0 Security Best Current Practice document. This is also the foundation of the upcoming OAuth 2.1.
To configure your solution for code flow + PKCE you have to set the responseType
to code
:
import { AuthConfig } from 'angular-oauth2-oidc';
export const authCodeFlowConfig: AuthConfig = {
// Url of the Identity Provider
issuer: 'https://idsvr4.azurewebsites.net',
// URL of the SPA to redirect the user to after login
redirectUri: window.location.origin + '/index.html',
// The SPA's id. The SPA is registerd with this id at the auth-server
// clientId: 'server.code',
clientId: 'spa',
// Just needed if your auth server demands a secret. In general, this
// is a sign that the auth server is not configured with SPAs in mind
// and it might not enforce further best practices vital for security
// such applications.
// dummyClientSecret: 'secret',
responseType: 'code',
// set the scope for the permissions the client should request
// The first four are defined by OIDC.
// Important: Request offline_access to get a refresh token
// The api scope is a usecase specific one
scope: 'openid profile email offline_access api',
showDebugInformation: true,
};
After this, you can initialize the code flow using:
this.oauthService.initCodeFlow();
There is also a convenience method initLoginFlow
which initializes either the code flow or the implicit flow depending on your configuration.
this.oauthService.initLoginFlow();
Also -- as shown in the readme -- you have to execute the following code when bootstrapping to make the library to fetch the token:
this.oauthService.configure(authCodeFlowConfig);
this.oauthService.loadDiscoveryDocumentAndTryLogin();
Logging out
The logOut method clears the used token store (by default sessionStorage
) and forwards the user to the auth servers logout endpoint if one was configured (manually or via the discovery document).
this.oauthService.logOut();
If you want to revoke the existing access token and the existing refresh token before logging out, use the following method:
this.oauthService.revokeTokenAndLogout();
Skipping the Login Form
If you don't want to display a login form that tells the user that they are redirected to the identity server, you can use the convenience function this.oauthService.loadDiscoveryDocumentAndLogin();
instead of this.oauthService.loadDiscoveryDocumentAndTryLogin();
when setting up the library.
This directly redirects the user to the identity server if there are no valid tokens. Ensure you have your issuer
set to your discovery document endpoint!
Calling a Web API with an Access Token
You can automate this task by switching sendAccessToken
on and by setting allowedUrls
to an array with prefixes for the respective URLs. Use lower case for the prefixes.
OAuthModule.forRoot({
resourceServer: {
allowedUrls: ['http://www.angular.at/api'],
sendAccessToken: true
}
})
If you need more versatility, you can look in the documentation how to setup a custom interceptor.
Token Refresh
Routing
If you use the PathLocationStrategy
(which is on by default) and have a general catch-all-route (path: '**'
) you should be fine. Otherwise look up the section Routing with the HashStrategy
in the documentation.
Implicit Flow
Nowadays, using code flow + PKCE -- as shown above -- is the recommended OAuth 2/OIDC flow for SPAs. To use the older implicit flow, lookup this docs: https://manfredsteyer.github.io/angular-oauth2-oidc/docs/additional-documentation/using-implicit-flow.html
More Documentation (!)
See the documentation for more information about this library.
Breaking Change in Version 9
With regards to tree shaking, beginning with version 9, the JwksValidationHandler
has been moved to a library of its own. If you need it for implementing implicit flow, please install it using npm:
npm i angular-oauth2-oidc-jwks --save
After that, you can import it into your application by using this:
import { JwksValidationHandler } from 'angular-oauth2-oidc-jwks';
instead of that:
import { JwksValidationHandler } from 'angular-oauth2-oidc';
Please note, that this dependency is not needed for the code flow, which is nowadays the recommended flow for single page applications. This also results in smaller bundle sizes.
Breaking change in 9.1.0
The use of encodeURIComponent
on the argument passed to initImplicitFlow
and its Code Flow counterparts was mandatory before this version.
Since that was considered a bug, the need to do so was removed. Now the reverse is true if you're upgrading from before 9.0.0: you need to remove any call to encode URI components in your own application, as the library will now do it for you.
Tutorials
- Tutorial with Demo Servers available online
- Angular Authentication with OpenID Connect and Okta in 20 Minutes
- Add Authentication to Your Angular PWA
- Build an Ionic App with User Authentication
- On-Site Workshops
- Angular 6 with Auth0 using this library
Thanks to all Contributors
Top Related Projects
OpenID Connect and OAuth 2.0 Framework for ASP.NET Core
Flexible and versatile OAuth 2.0/OpenID Connect stack for .NET
npm package for OpenID Connect, OAuth Code Flow with PKCE, Refresh tokens, Implicit Flow
OpenID Connect (OIDC) and OAuth2 protocol support for browser-based JavaScript applications
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot