OAuth 2.0 Authorization Server using NodeJS and ExpressJS (Part-1)

6 min readJul 24, 2021

Introduction

This Article is basically about How to Implement your own OpenID Connect (OIDC) Provider in NodeJS using node oidc-provider library.

If you want to implement OIDC Client in Nodejs, you can follow my this article.

Prerequisite

In this article we are not going to learn how OAuth works..So, It is highly recommended to read once about following topics:

What is OAuth 2.0?
What are different Grant Types in OAuth 2.0 and what are there flow ?
What is OpenID Connect and How It is different from OAuth 2.0 ?

Lets go through some basic terms used in this article.

Brief Description of OAuth 2.0

What is OAuth 2.0 ?
What Is OpenID Connect ?
OAuth 2.0 Grant Types
Parameters for Auth endpoint
How openID Connect Works ?

2. Step-By-Step Implemetation Of own OpenID Connect Provider

3. Testing of created OIDC provider

1. Brief Description of OAuth 2.0

1.1. What is OAuth 2.0 ?

The OAuth 2.0 authorization framework is a protocol that allows a user to grant a third-party web site or application access to the user’s protected resources, without necessarily revealing their long-term credentials or even their identity.
Remember It is Authorization, not Authentication.

1.2. What Is OpenID Connect ?

OpenID Connect (OIDC) is an identity layer built on top of the OAuth 2.0 framework.
It allows third-party applications to verify the identity of the end-user and to obtain basic user profile information.

1.3. OAuth2.0 vs OIDC

The first thing to understand is that OAuth 2.0 is an authorization framework, not an authentication protocol.
From a technical perspective, the big difference between OpenID Connect and OAuth 2.0 is the id_token–there is no id_token defined in OAuth 2.0 because it is specific to federated authentication.
The id_token provides an additional layer of security to user sign in transactions by adding:

— A nonce, which is sent by the client and enables the integrity of the response to be validated.

— A hash of the access token.

— A hash of the code (optional)

1.4. OAuth 2.0 Grant Types :

OAuth 2.0 defines four flows to get an access token. These flows are called grant types.

Authorization Code Flow
Implicit Flow with Form Post
Resource Owner Password Flow
Client Credentials Flow

Lets see in brief about these grants Types. For more details you can read here

1.4.1 Authorization Code

Flow used by Web Apps executing on a server.
This is also used by mobile apps, using the Proof Key for Code Exchange (PKCE) technique.
Because regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow, which exchanges an Authorization Code for a token.
During authentication, mobile and native applications can use the Authorization Code Flow, but they require additional security. Additionally, single-page apps have special challenges. To mitigate these, OAuth 2.0 provides a version of the Authorization Code Flow which makes use of a Proof Key for Code Exchange (PKCE).

1.4.2. Implicit Flow With Form Post

used by JavaScript-centric apps (Single-Page Applications) executing on the user’s browser.
It is intended for Public Clients, or applications which are unable to securely store Client Secrets. While this is no longer considered a best practice for requesting Access Tokens, when used with Form Post response mode, it does offer a streamlined workflow if the application needs only an ID token to perform user authentication.

1.4.3. Resource Owner Password Flow

used by highly-trusted apps.
Though we do not recommend it, highly-trusted applications can use the Resource Owner Password Flow, which requests that users provide credentials (username and password), typically using an interactive form. The Resource Owner Password Flow should only be used when redirect-based flows (like the Authorization Code Flow) cannot be used.

1.4.4. Client Credentials Flow

used for machine-to-machine communication.
With machine-to-machine (M2M) applications, such as CLIs, daemons, or services running on your back-end, the system authenticates and authorizes the app rather than a user. For this scenario, typical authentication schemes like username + password or social logins don’t make sense. Instead, M2M apps use the Client Credentials Flow

1.5. Parameters for Auth endpoint

http://localhost:3000/auth?response_type=code&redirect_uri=http://localhost:8080/login/callback&scope=profile&client_id=oidcCLIENT

response_type

response_type will be set to code, indicating that the application expects to receive an authorization code if successful.

client_id

The client_id is the public identifier for the app.

redirect_uri

This URL must match one of the URLs the developer registered when creating the application, and the authorization server should reject the request if it does not match.

scope

The request may have one or more scope values indicating additional access requested by the application. The authorization server will need to display the requested scopes to the user.

state

The state parameter is used by the application to store request-specific data and/or prevent CSRF attacks. The authorization server must return the unmodified state value back to the application.

1.6 How OpenID Connect Works ?

The application starts with an OAuth flow that asks the user to authorize a request. As part of that flow, the client will include the OpenID Connect scope along with scopes for any additional information it wants about the user.

After the request is processed, the client will receive an access token as well as an ID token issued by the authorization server that contains claims that carry information about the user. The user’s SSO experience is made possible by the delivery of the ID token from the authorization server to the client. The client can then contact a special endpoint on the authorization server known as the UserInfo endpoint to receive the remaining claims about the user.

OpenID Connect also defines mechanisms for discovery and session management beyond OAuth.

2. Step-By-Step Implemetation Of own OpenID Connect Provider

We will use npm to create our oidc-provider project, First, let’s create our project directory, then we run the init command

mkdir OIDC
cd OIDC
npm init -y

2. Install required packages

npm i express nodemon oidc-provider ejsor yarn add express nodemon oidc-provider ejs

3. create a index.js file and write following codes

const express = require('express');const app = express();//Middlewares
app.use(express.static(__dirname + '/public'));
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'ejs');app.listen(3000, function () {
  console.log('OIDC is listening on port 3000!');
});

4. Add OIDC Configuration in index.js

const { Provider } = require('oidc-provider');const configuration = {
clients: [{
     client_id: "oidcCLIENT",
     client_secret: "Some_super_secret",
     grant_types: ["authorization_code"],
     redirect_uris: [ "http://localhost:8080/auth/login/callback"],
     response_types: ["code",],
     //other configurations if needed
}],
pkce: {
required: () => false,
},
};const oidc = new Provider('http://localhost:3000', configuration);
app.use("/oidc",oidc.callback());

So Final index.js will be something like this.

5. Run application by

nodemon index.js

6. You can view configuration of openid by visiting following link, You will see page similar to below

http://localhost:3000/oidc/.well-known/openid-configuration

Congatulations !! You have created Your Own basicOIDC Provider.

For customized OIDC Provider read more here.

3. Testing of created OIDC provider

Let’s See how to test our created OIDC-Provider

Implement Your own OIDC-client

follow this beautiful article.

2. We can also test using Online oidc debugger.

Go to https://oidcdebugger.com/ or you can use any oidc clientof your choice.
Fill your oidc-provider details like this

3. Add https://oidcdebugger.com/debug to redirect_uri in index.js

redirect_uris: [ "https://oidcdebugger.com/debug"],

4. After Clicking Send request, You will see PAge like this, Enter any data in the fields and signIn. These Pages are default pages provided by oidc-provider