0

node-openid-client

OpenID Certified™ Relying Party (OpenID Connect/OAuth 2.0 Client) implementation for Node.js.

Github 資源庫
主要指標

Github星跟蹤圖

openid-client

openid-client is a server side OpenID Relying Party (RP, Client) implementation for
Node.js runtime, supports passport.

Implemented specs & features

The following client/RP features from OpenID Connect/OAuth2.0 specifications are implemented by
openid-client.

Updates to draft specifications (DPoP, JARM, and FAPI) are released as MINOR library versions,
if you utilize these specification implementations consider using the tilde ~ operator in your
package.json since breaking changes may be introduced as part of these version updates.

Certification


Filip Skokan has certified that openid-client
conforms to the following profiles of the OpenID Connect™ protocol

  • RP Basic, Implicit, Hybrid, Config, Dynamic, and Form Post
  • RP FAPI R/W MTLS and Private Key

If you want to quickly add OpenID Connect authentication to Node.js apps, feel free to check out Auth0's Node.js SDK and free plan at auth0.com/developers.

Support

If you or your business use openid-client, please consider becoming a sponsor so I can continue maintaining it and adding new features carefree.

Documentation

The library exposes what are essentially steps necessary to be done by a relying party consuming
OpenID Connect Authorization Server responses or wrappers around requests to its endpoints. Aside
from a generic OpenID Connect passport strategy it does not expose neither express
or koa middlewares. Those can however be built using the exposed API.

Install

Node.js version >=12.0.0 is recommended, but ^10.19.0 lts/dubnium is also supported.

npm install openid-client

Quick start

Discover an Issuer configuration using its published .well-known endpoints

const { Issuer } = require('openid-client');
Issuer.discover('https://accounts.google.com') // => Promise
  .then(function (googleIssuer) {
    console.log('Discovered issuer %s %O', googleIssuer.issuer, googleIssuer.metadata);
  });

Authorization Code Flow

Authorization Code flow is for obtaining Access Tokens (and optionally Refresh Tokens) to use with
third party APIs securely as well as Refresh Tokens. In this quick start your application also uses
PKCE instead of state parameter for CSRF protection.

Create a Client instance for that issuer's authorization server intended for Authorization Code
flow.

See the documentation for full API details.

const client = new googleIssuer.Client({
  client_id: 'zELcpfANLqY7Oqas',
  client_secret: 'TQV5U29k1gHibH5bx1layBo0OSAvAbRT3UYW3EWrSYBB5swxjVfWUa1BS8lqzxG/0v9wruMcrGadany3',
  redirect_uris: ['http://localhost:3000/cb'],
  response_types: ['code'],
  // id_token_signed_response_alg (default "RS256")
  // token_endpoint_auth_method (default "client_secret_basic")
}); // => Client

When you want to have your end-users authorize you need to send them to the issuer'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.

const { generators } = require('openid-client');
const code_verifier = generators.codeVerifier();
// store the code_verifier in your framework's session mechanism, if it is a cookie based solution
// it should be httpOnly (not readable by javascript) and encrypted.

const code_challenge = generators.codeChallenge(code_verifier);

client.authorizationUrl({
  scope: 'openid email profile',
  resource: 'https://my.api.example.com/resource/32178',
  code_challenge,
  code_challenge_method: 'S256',
});

When end-users are redirected back to your redirect_uri your application consumes the callback and
passes in the code_verifier to include it in the authorization code grant token exchange.

const params = client.callbackParams(req);
client.callback('https://client.example.com/callback', params, { code_verifier }) // => Promise
  .then(function (tokenSet) {
    console.log('received and validated tokens %j', tokenSet);
    console.log('validated ID Token claims %j', tokenSet.claims());
  });

You can then call the userinfo_endpoint.

client.userinfo(access_token) // => Promise
  .then(function (userinfo) {
    console.log('userinfo %j', userinfo);
  });

And later refresh the tokenSet if it had a refresh_token.

client.refresh(refresh_token) // => Promise
  .then(function (tokenSet) {
    console.log('refreshed and validated tokens %j', tokenSet);
    console.log('refreshed ID Token claims %j', tokenSet.claims());
  });

Implicit ID Token Flow

Implicit response_type=id_token flow is perfect for simply authenticating your end-users, assuming
the only job you want done is authenticating the user and then relying on your own session mechanism
with no need for accessing any third party APIs with an Access Token from the Authorization Server.

Create a Client instance for that issuer's authorization server intended for ID Token implicit flow.

See the documentation for full API details.

const client = new googleIssuer.Client({
  client_id: 'zELcpfANLqY7Oqas',
  redirect_uris: ['http://localhost:3000/cb'],
  response_types: ['id_token'],
  // id_token_signed_response_alg (default "RS256")
}); // => Client

When you want to have your end-users authorize you need to send them to the issuer'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.

const { generators } = require('openid-client');
const nonce = generators.nonce();
// store the nonce in your framework's session mechanism, if it is a cookie based solution
// it should be httpOnly (not readable by javascript) and encrypted.

client.authorizationUrl({
  scope: 'openid email profile',
  response_mode: 'form_post',
  nonce,
});

When end-users hit back your redirect_uri with a POST (authorization request included form_post
response mode) your application consumes the callback and passes the nonce in to include it in the
ID Token verification steps.

// assumes req.body is populated from your web framework's body parser
const params = client.callbackParams(req);
client.callback('https://client.example.com/callback', params, { nonce }) // => Promise
  .then(function (tokenSet) {
    console.log('received and validated tokens %j', tokenSet);
    console.log('validated ID Token claims %j', tokenSet.claims());
  });

Device Authorization Grant (Device Flow)

RFC8628 - OAuth 2.0 Device Authorization Grant (Device Flow)
is started by starting a Device Authorization Request.

const handle = await client.deviceAuthorization();
console.log('User Code: ', handle.user_code);
console.log('Verification URI: ', handle.verification_uri);
console.log('Verification URI (complete): ', handle.verification_uri_complete);

The handle represents a Device Authorization Response with the verification_uri, user_code and
other defined response properties.

You will display the instructions to the end-user and have him directed at verification_uri or
verification_uri_complete, afterwards you can start polling for the Device Access Token Response.

const tokenSet = await handle.poll();
console.log('received tokens %j', tokenSet);

This will poll in the defined interval and only resolve with a TokenSet once one is received. This
will handle the defined authorization_pending and slow_down "soft" errors and continue polling
but upon any other error it will reject. With tokenSet received you can throw away the handle.

Electron Support

Electron >=v6.0.0 runtime is supported to the extent of the crypto engine BoringSSL feature parity
with standard Node.js OpenSSL.

FAQ

Semver?

Yes. Everything that's either exported in the TypeScript definitions file or
documented is subject to
Semantic Versioning 2.0.0. The rest is to be considered
private API and is subject to change between any versions.

How do I use it outside of Node.js

It is only built for ^10.19.0, >=12.0.0 Node.js environment - including openid-client in
browser-environment targeted projects is not supported and may result in unexpected results.

What's new in 3.x?

  • Simplified API which consumes a lot of the common configuration issues
  • New documentation
  • Added support for mutual-TLS client authentication
  • Added support for any additional token exchange parameters to support specifications such as
    Resource Indicators
  • Typed errors
  • TypeScript definitions

How to make the client send client_id and client_secret in the body?

See Client Authentication Methods (docs).

Can I adjust the HTTP timeout?

See Customizing (docs).

How can I debug the requests and responses?

See Customizing (docs).

主要指標

概覽
名稱與所有者panva/openid-client
主編程語言TypeScript
編程語言JavaScript (語言數: 3)
平台
許可證MIT License
所有者活动
創建於2016-06-27 08:11:27
推送於2025-05-12 08:24:42
最后一次提交
發布數204
最新版本名稱v6.5.0 (發布於 2025-05-06 20:17:03)
第一版名稱v0.1.0 (發布於 2016-07-14 18:30:41)
用户参与
星數2k
關注者數28
派生數400
提交數1.1k
已啟用問題?
問題數348
打開的問題數0
拉請求數75
打開的拉請求數0
關閉的拉請求數63
项目设置
已啟用Wiki?
已存檔?
是復刻?
已鎖定?
是鏡像?
是私有?