OpenID Connect (OIDC) client libraries are essential tools for implementing authentication flows in web applications. They simplify the process of integrating with OIDC providers, allowing developers to manage user authentication, token handling, and session management efficiently. The two libraries, 'oidc-client' and 'openid-client', serve similar purposes but cater to different use cases and architectural preferences, making it crucial to understand their unique features and functionalities.
Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
openid-client
3,006,236
2,049
201 kB
0
8 days ago
MIT
oidc-client
150,162
2,433
-
116
4 years ago
Apache-2.0
Feature Comparison: openid-client vs oidc-client
Use Case
openid-client:
The 'openid-client' library is designed for server-side applications, making it suitable for scenarios where the backend needs to handle user authentication, token management, and secure API calls. It supports various OIDC flows, allowing developers to implement complex authentication mechanisms that require server-side logic.
oidc-client:
The 'oidc-client' library is specifically tailored for client-side applications, particularly single-page applications (SPAs). It excels in scenarios where the application needs to authenticate users directly in the browser and manage tokens without involving a backend server. This makes it ideal for modern web applications that prioritize user experience and responsiveness.
Token Management
openid-client:
'openid-client' offers extensive token management capabilities, including token validation, introspection, and revocation. It allows developers to implement secure token handling on the server side, ensuring that sensitive operations are performed in a secure environment.
oidc-client:
'oidc-client' provides built-in mechanisms for managing access and refresh tokens directly in the browser. It automatically handles token renewal and session management, allowing developers to focus on building user interfaces without worrying about the underlying authentication logic.
Complexity and Learning Curve
openid-client:
The 'openid-client' library has a steeper learning curve due to its comprehensive feature set and the need for a deeper understanding of OIDC flows and server-side authentication. It requires more configuration and knowledge about backend development, making it more suitable for experienced developers or teams familiar with OIDC.
oidc-client:
The 'oidc-client' library is relatively easy to integrate into client-side applications, with a straightforward API and minimal configuration required. This makes it accessible for developers who may not have extensive experience with OIDC or authentication protocols, allowing for quick implementation and deployment.
Extensibility
openid-client:
'openid-client' provides a rich set of features and options for customization, including support for custom client authentication methods, handling different response types, and integrating with various OIDC providers. This extensibility makes it a powerful choice for complex applications that require tailored authentication solutions.
oidc-client:
'oidc-client' is designed to be extensible, allowing developers to customize its behavior through events and callbacks. This flexibility enables developers to tailor the authentication process to meet specific application needs, such as integrating with custom user interfaces or handling specific authentication scenarios.
Community and Support
openid-client:
'openid-client' also has a robust community and is well-documented, providing extensive resources for developers. Its popularity in server-side applications means that there are numerous examples and use cases available, making it easier to find solutions to common challenges encountered during implementation.
oidc-client:
'oidc-client' has a strong community and is widely used in the SPA development ecosystem. It benefits from active maintenance and regular updates, ensuring compatibility with the latest OIDC specifications and browser standards. The community support makes it easier to find resources and examples for implementation.
How to Choose: openid-client vs oidc-client
openid-client:
Choose 'openid-client' if you are building a server-side application or need a more comprehensive solution that supports various OIDC flows, including authorization code flow and client credentials flow. This library is suitable for backend applications where you need to handle token exchange and user authentication securely on the server.
oidc-client:
Choose 'oidc-client' if you need a lightweight, browser-based solution for handling OIDC authentication in single-page applications (SPAs). It is designed for client-side usage and provides features like automatic token renewal and session management, making it ideal for applications that require seamless user experiences without server-side involvement.
Similar Npm Packages to openid-client
openid-client is a powerful and flexible OpenID Connect (OIDC) client library for Node.js applications. It allows developers to easily integrate OIDC authentication into their applications, enabling secure user authentication and authorization. With support for various OIDC providers, openid-client simplifies the process of managing tokens, handling redirects, and making authenticated requests to APIs. Its robust features make it a popular choice for applications that require secure user authentication and seamless integration with OIDC-compliant identity providers.
An alternative to openid-client is oidc-client. This library is specifically designed for client-side applications, such as single-page applications (SPAs), and provides a simple way to manage OIDC authentication flows. oidc-client focuses on handling user sessions, managing tokens, and facilitating interactions with OIDC providers from the browser. It is well-suited for applications that require a lightweight solution for OIDC authentication without the need for extensive server-side logic.
oidc-client is a JavaScript library designed for handling OpenID Connect (OIDC) authentication in web applications. It provides a simple way to manage user authentication, including token management, user sessions, and interaction with OIDC providers. While oidc-client is a robust solution for OIDC authentication, there are several alternatives in the ecosystem that cater to similar needs. Here are a few noteworthy alternatives:
oidc-client-ts is a TypeScript version of the original oidc-client library. It retains the same core functionality while providing type safety and improved developer experience for TypeScript users. If you're building a TypeScript application and want to leverage the benefits of strong typing while managing OIDC authentication, oidc-client-ts is an excellent choice.
oidc-provider is a library for implementing an OpenID Connect provider. Unlike the other libraries mentioned, which focus on client-side authentication, oidc-provider is designed for server-side applications. It allows developers to create their own OIDC-compliant identity provider, enabling them to manage user authentication and authorization flows. If you're looking to build a custom OIDC provider for your applications, oidc-provider is the go-to solution.
openid-client is another library that provides a client implementation for OpenID Connect. It is designed to work with any OpenID Connect provider and offers a comprehensive set of features for handling authentication and token management. openid-client is particularly useful for server-side applications that need to interact with OIDC providers. If you require flexibility in choosing your OIDC provider and need a robust client implementation, openid-client is a strong candidate.
react-oidc-context is a React-specific library that simplifies the integration of OIDC authentication in React applications. It provides a context-based approach to managing authentication state and user sessions, making it easy to access authentication information throughout your React components. If you are building a React application and want a seamless way to manage OIDC authentication, react-oidc-context is a great option.
OAuth 2 / OpenID Connect Client API for JavaScript Runtimes
openid-client simplifies integration with authorization servers by providing easy-to-use APIs for the most common authentication and authorization flows, including OAuth 2 and OpenID Connect. It is designed for JavaScript runtimes like Node.js, Browsers, Deno, Cloudflare Workers, and more.
Features
The following features are currently in scope and implemented in this software:
Authorization Server Metadata discovery
Authorization Code Flow (profiled under OpenID Connect 1.0, OAuth 2.0, OAuth 2.1, FAPI 1.0 Advanced, and FAPI 2.0)
If you want to quickly add authentication to JavaScript apps, feel free to check out Auth0's JavaScript SDK and free plan. Create an Auth0 account; it's free!
Filip Skokan has certified that this software conforms to the Basic, FAPI 1.0, and FAPI 2.0 Relying Party Conformance Profiles of the OpenID Connect™ protocol.
Support from the community to continue maintaining and improving this module is welcome. If you find the module useful, please consider supporting the project by becoming a sponsor.
let server!: URL // Authorization Server's Issuer Identifier
let clientId!: string // Client identifier at the Authorization Server
let clientSecret!: string // Client Secret
let config: client.Configuration = await client.discovery(
server,
clientId,
clientSecret,
)
Authorization Code Flow
Authorization Code flow is for obtaining Access Tokens (and optionally Refresh Tokens) to use with
third party APIs.
When you want to have your end-users authorize or authenticate you need to send them to the authorization server's authorization_endpoint. Consult the web framework of your choice on how to redirect but here's how
to get the authorization endpoint's URL with parameters already encoded in the query to redirect
to.
/**
* Value used in the authorization request as the redirect_uri parameter, this
* is typically pre-registered at the Authorization Server.
*/
let redirect_uri!: string
let scope!: string // Scope of the access request
/**
* PKCE: The following MUST be generated for every redirect to the
* authorization_endpoint. You must store the code_verifier and state in the
* end-user session such that it can be recovered as the user gets redirected
* from the authorization server back to your application.
*/
let code_verifier: string = client.randomPKCECodeVerifier()
let code_challenge: string =
await client.calculatePKCECodeChallenge(code_verifier)
let state!: string
let parameters: Record<string, string> = {
redirect_uri,
scope,
code_challenge,
code_challenge_method: 'S256',
}
if (!config.serverMetadata().supportsPKCE()) {
/**
* We cannot be sure the server supports PKCE so we're going to use state too.
* Use of PKCE is backwards compatible even if the AS doesn't support it which
* is why we're using it regardless. Like PKCE, random state must be generated
* for every redirect to the authorization_endpoint.
*/
state = client.randomState()
parameters.state = state
}
let redirectTo: URL = client.buildAuthorizationUrl(config, parameters)
// now redirect the user to redirectTo.href
console.log('redirecting to', redirectTo.href)
When end-users are redirected back to the redirect_uri your application consumes the callback and
passes in PKCE code_verifier to include it in the authorization code grant token exchange.
let protectedResourceResponse: Response = await client.fetchProtectedResource(
config,
tokens.access_token,
new URL('https://rs.example.com/api'),
'GET',
)
console.log(
'Protected Resource Response',
await protectedResourceResponse.json(),
)
Device Authorization Grant (Device Flow)
let scope!: string // Scope of the access request
let response = await client.initiateDeviceAuthorization(config, { scope })
console.log('User Code:', response.user_code)
console.log('Verification URI:', response.verification_uri)
console.log('Verification URI (complete):', response.verification_uri_complete)
You will display the instructions to the end-user and have them directed at verification_uri or
verification_uri_complete, afterwards you can start polling for the Device Access Token Response.
let scope!: string // Scope of the access request
/**
* One of login_hint, id_token_hint, or login_hint_token parameters must be
* provided in CIBA
*/
let login_hint!: string
let response = await client.initiateBackchannelAuthentication(config, {
scope,
login_hint,
})
/**
* OPTIONAL: If your client is configured with Ping Mode you'd invoke the
* following after getting the CIBA Ping Callback (its implementation is
* framework specific and therefore out of scope for openid-client)
*/
let tokens: client.TokenEndpointResponse =
await client.pollBackchannelAuthenticationGrant(config, response)
console.log('Token Endpoint Response', tokens)
This will poll in a regular interval and only resolve with tokens once the end-user authenticates.
Client Credentials Grant
Client Credentials flow is for obtaining Access Tokens to use with third party APIs on behalf of your application, rather than an end-user which was the case in previous examples.
let scope!: string // Scope of the access request
let resource!: string // Resource Indicator of the Resource Server the access token is for
let tokens: client.TokenEndpointResponse = await lib.clientCredentialsGrant(
config,
{ scope, resource },
)
console.log('Token Endpoint Response', tokens)
Supported Runtimes
The supported JavaScript runtimes include those that support the utilized Web API globals and standard built-in objects. These are (but are not limited to):
Browsers
Bun
Cloudflare Workers
Deno
Electron
Node.js[^nodejs]
Vercel's Edge Runtime
Supported Versions
| Version | Security Fixes 🔑 | Other Bug Fixes 🐞 | New Features ⭐ | Runtime and Module type |
| -------------------------------------------------------- | ----------------- | ------------------ | --------------- | ------------------------------- |
| v6.x | Security Policy | ✅ | ✅ | Universal[^universal] ESM[^cjs] |
| v5.x | Security Policy | ❌ | ❌ | Node.js CJS + ESM |
[^cjs]: CJS style let client = require('openid-client') is possible in Node.js versions where the require(esm) feature is enabled by default (^20.19.0 || ^22.12.0 || >= 23.0.0).