Passport OpenID Connect

Note: Fork of Jared Hansen's Passport strategy for authenticating with OpenID Connect.

This module lets you authenticate using OpenID Connect in your Node.js applications. By plugging into Passport, OpenID Connect-based sign in can be easily and unobtrusively integrated into any application or framework that supports Connect-style middleware, including Express.

Install

1npm install @techpass/passport-openidconnect

If you are coding in typescript, this library has native typings support. But you may need to install type definitions for express and passport-strategy separately as there is a dependency on them.

To install these typings from the DefinitelyTyped project run: npm i -D @types/express @types/passport-strategy.

Usage

Configure Strategy

The OpenID Connect authentication strategy authenticates users using their account at an OpenID Provider (OP). The strategy needs to be configured with the provider's endpoints, in order to function properly. Consult the provider's documentation for the locations of these endpoints and instructions on how to register a client.

The Strategy constructor takes in the following options:

1/**
2 * Options available to pass into Strategy constructor during instantiation.
3 *
4 * @see https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest
5 */
6interface StrategyOptions {
7  issuer: string;
8  authorizationURL: string;
9  tokenURL: string;
10  callbackURL: string;
11  userInfoURL: string;
12  clientID: string;
13  clientSecret: string;
14  acrValues?: string;
15  claims?: object;
16  customHeaders?: OutgoingHttpHeaders;
17  display?: string;
18  idTokenHint?: string;
19  loginHint?: string;
20  maxAge?: string;
21  prompt?: string;
22  proxy?: boolean;
23  responseMode?: string;
24  scope?: string | string[];
25  uiLocales?: string;
26
27  /**
28   * If defined, an internally generated nonce will be added to the client request to mitigate replay attacks.
29   *
30   * @see https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes
31   */
32  nonce?: boolean;
33  /**
34   * Http client agent. If undefined, the default node agent is used.
35   *
36   * @see https://nodejs.org/api/http.html#class-httpagent
37   */
38  agent?: Agent;
39  /**
40   * If defined, the {@link express.Request | Request} object will be passed into {@link VerifyFunction}
41   */
42  passReqToCallback?: boolean;
43  /**
44   * Defines a PKCE protocol to use. If undefined, PKCE is not used.
45   *
46   * @see https://oauth.net/2/pkce/
47   */
48  pkce?: "S256" | "plain";
49  /**
50   * Unique session identifier for this issuer.
51   * If none is given, the issuer's hostname will be used.
52   */
53  sessionKey?: string;
54  /**
55   * Custom session store instance with interface compliant to {@link SessionStore}.
56   * If undefined, the internal store will be used.
57   */
58  store?: SessionStore;
59  /**
60   * Determines if user data is loaded from /userInfo endpoint. If not specified, loading of userInfo
61   * is decided by arity of {@link VerifyFunction} and value of `passReqToCallback`
62   */
63  skipUserProfile?:
64    | boolean
65    | ((
66        req: express.Request,
67        claims: any,
68        done: (err: Error | null, skip: boolean) => void
69      ) => void)
70    | ((req: express.Request, claims: any) => boolean);
71}

Verify Function

The strategy constructor also takes a verify function as an argument, which is responsible for processing the authenticated user info that the OP returns.

The function accepts issuer, profile and done callback as arguments. issuer is set to an identifier for the OP and profile contains the user's profile information stored in their account at the OP.

The done callback is invoked to end processing for the middleware and return either an error a user object that is local to the application together with any additional auth info.

Depending on skipUserProfile and arity of verify function, the returning profile may contain:

• data parse from id_token claim
• merge data from both id_token claim & userInfo endpoint

Instead of a single profile instance, you can get the strategy to return profile from id_token and userInfo endpoint separately. They will return as idProfile and uiProfile.

Check out the overloads available for the function in the code for more info.

Typically, when the account is logging in for the first time, a new user record is created in the application. On subsequent logins, the existing user record will be found via its relation to the OP account.

Because the verify function is supplied by the application, the app is free to use any database of its choosing. The example below illustrates usage of a SQL database.

1const OpenIDConnectStrategy = require("@techpass/passport-openidconnect");
2
3passport.use(
4  new OpenIDConnectStrategy(
5    {
6      issuer: "https://server.example.com",
7      authorizationURL: "https://server.example.com/authorize",
8      tokenURL: "https://server.example.com/token",
9      userInfoURL: "https://server.example.com/userinfo",
10      clientID: process.env["CLIENT_ID"],
11      clientSecret: process.env["CLIENT_SECRET"],
12      callbackURL: "https://client.example.org/cb",
13    },
14    function verify(issuer, profile, done) {
15      db.get(
16        "SELECT * FROM federated_credentials WHERE provider = ? AND subject = ?",
17        [issuer, profile.id],
18        function (err, cred) {
19          if (err) {
20            return done(err);
21          }
22
23          if (!cred) {
24            // The account at the OpenID Provider (OP) has not logged in to this app
25            // before.  Create a new user account and associate it with the account
26            // at the OP.
27            db.run(
28              "INSERT INTO users (name) VALUES (?)",
29              [profile.displayName],
30              function (err) {
31                if (err) {
32                  return done(err);
33                }
34
35                var id = this.lastID;
36                db.run(
37                  "INSERT INTO federated_credentials (user_id, provider, subject) VALUES (?, ?, ?)",
38                  [id, issuer, profile.id],
39                  function (err) {
40                    if (err) {
41                      return done(err);
42                    }
43                    var user = {
44                      id: id,
45                      name: profile.displayName,
46                    };
47                    return done(null, user);
48                  }
49                );
50              }
51            );
52          } else {
53            // The account at the OpenID Provider (OP) has previously logged in to
54            // the app.  Get the user account associated with the account at the OP
55            // and log the user in.
56            db.get(
57              "SELECT * FROM users WHERE id = ?",
58              [cred.user_id],
59              function (err, row) {
60                if (err) {
61                  return done(err);
62                }
63                if (!row) {
64                  return done(null, false);
65                }
66                return done(null, row);
67              }
68            );
69          }
70        }
71      );
72    }
73  )
74);

Define Routes

Two routes are needed in order to allow users to log in with their account at an OP. The first route redirects the user to the OP, where they will authenticate:

1app.get("/login", passport.authenticate("openidconnect"));

The second route processes the authentication response and logs the user in, when the OP redirects the user back to the app:

1app.get(
2  "/cb",
3  passport.authenticate("openidconnect", {
4    failureRedirect: "/login",
5    failureMessage: true,
6  }),
7  function (req, res) {
8    res.redirect("/");
9  }
10);

Examples

• todos-express-openidconnect

  Illustrates how to use the OpenID Connect strategy within an Express application.

• todos-express-auth0

  Illustrates how to use the OpenID Connect strategy to integrate with Auth0 in an Express application. For developers new to Passport and getting started, a tutorial is available.

Changelog

See CHANGELOG.

Credits

• Original Author: Jared Hansen
• Fork Contributor(s): GovTechSG

License

See LICENSE for more info.