96c0d0c9c8
Update nodejs-adapter.adoc Removed git instructions formatting app.use code block Update securing_apps/topics/oidc/nodejs-adapter.adoc Co-authored-by: Jon Koops <jonkoops@gmail.com>
383 lines
14 KiB
Text
383 lines
14 KiB
Text
[[_nodejs_adapter]]
|
|
=== Node.js adapter
|
|
|
|
{project_name} provides a Node.js adapter built on top of https://github.com/senchalabs/connect[Connect] to protect server-side JavaScript apps - the goal was to be flexible enough to integrate with frameworks like https://expressjs.com/[Express.js].
|
|
|
|
ifeval::[{project_community}==true]
|
|
The library can be downloaded directly from https://www.npmjs.com/package/keycloak-connect[ {project_name} organization] and the source is available at
|
|
https://github.com/keycloak/keycloak-nodejs-connect[GitHub].
|
|
endif::[]
|
|
|
|
To use the Node.js adapter, first you must create a client for your application in the {project_name} Admin Console. The adapter supports public, confidential, and bearer-only access type. Which one to choose depends on the use-case scenario.
|
|
|
|
Once the client is created click the `Installation` tab, select `{project_name} OIDC JSON` for `Format Option`, and then click `Download`. The downloaded `keycloak.json` file should be at the root folder of your project.
|
|
|
|
==== Installation
|
|
|
|
Assuming you've already installed https://nodejs.org[Node.js], create a folder for your application:
|
|
|
|
mkdir myapp && cd myapp
|
|
|
|
Use `npm init` command to create a `package.json` for your application. Now add the {project_name} connect adapter in the dependencies list:
|
|
|
|
ifeval::[{project_community}==true]
|
|
|
|
[source,json,subs="attributes"]
|
|
----
|
|
"dependencies": {
|
|
"keycloak-connect": "{project_versionNpm}"
|
|
}
|
|
----
|
|
|
|
endif::[]
|
|
|
|
ifeval::[{project_product}==true]
|
|
|
|
[source,json,subs="attributes"]
|
|
----
|
|
"dependencies": {
|
|
"keycloak-connect": "file:keycloak-connect-{project_versionNpm}.tgz"
|
|
}
|
|
----
|
|
|
|
endif::[]
|
|
|
|
==== Usage
|
|
Instantiate a Keycloak class::
|
|
|
|
The `Keycloak` class provides a central point for configuration
|
|
and integration with your application. The simplest creation
|
|
involves no arguments.
|
|
|
|
In the root directory of your project create a file called `server.js` and add the following code:
|
|
|
|
[source,javascript]
|
|
----
|
|
const session = require('express-session');
|
|
const Keycloak = require('keycloak-connect');
|
|
|
|
const memoryStore = new session.MemoryStore();
|
|
const keycloak = new Keycloak({ store: memoryStore });
|
|
----
|
|
|
|
Install the `express-session` dependency:
|
|
|
|
----
|
|
npm install express-session
|
|
----
|
|
|
|
To start the `server.js` script, add the following command in the 'scripts' section of the `package.json`:
|
|
|
|
----
|
|
"scripts": {
|
|
"test": "echo \"Error: no test specified\" && exit 1",
|
|
"start" "node server.js"
|
|
},
|
|
----
|
|
|
|
Now we have the ability to run our server with following command:
|
|
|
|
----
|
|
npm run start
|
|
----
|
|
|
|
By default, this will locate a file named `keycloak.json` alongside
|
|
the main executable of your application, in our case on the root folder, to initialize keycloak-specific
|
|
settings such as public key, realm name, various URLs.
|
|
|
|
In that case a Keycloak deployment is necessary to access Keycloak admin console.
|
|
|
|
Please visit links on how to deploy a Keycloak admin console with
|
|
https://www.keycloak.org/getting-started/getting-started-podman[Podman] or https://www.keycloak.org/getting-started/getting-started-docker[Docker]
|
|
|
|
Now we are ready to obtain the `keycloak.json` file by visiting the {project_name} Admin Console -> clients (left sidebar) -> choose your client -> Installation -> Format Option -> Keycloak OIDC JSON -> Download
|
|
|
|
Paste the downloaded file on the root folder of our project.
|
|
|
|
Instantiation with this method results in all of the reasonable defaults
|
|
being used. As alternative, it's also possible to provide a configuration
|
|
object, rather than the `keycloak.json` file:
|
|
|
|
[source,javascript,subs="attributes+"]
|
|
----
|
|
const kcConfig = {
|
|
clientId: 'myclient',
|
|
bearerOnly: true,
|
|
serverUrl: 'http://localhost:8080{kc_base_path}',
|
|
realm: 'myrealm',
|
|
realmPublicKey: 'MIIBIjANB...'
|
|
};
|
|
|
|
const keycloak = new Keycloak({ store: memoryStore }, kcConfig);
|
|
----
|
|
|
|
Applications can also redirect users to their preferred identity provider by using:
|
|
[source,javascript]
|
|
----
|
|
const keycloak = new Keycloak({ store: memoryStore, idpHint: myIdP }, kcConfig);
|
|
----
|
|
|
|
Configuring a web session store::
|
|
|
|
If you want to use web sessions to manage
|
|
server-side state for authentication, you need to initialize the
|
|
`Keycloak(...)` with at least a `store` parameter, passing in the actual
|
|
session store that `express-session` is using.
|
|
[source,javascript]
|
|
----
|
|
const session = require('express-session');
|
|
const memoryStore = new session.MemoryStore();
|
|
|
|
// Configure session
|
|
app.use(
|
|
session({
|
|
secret: 'mySecret',
|
|
resave: false,
|
|
saveUninitialized: true,
|
|
store: memoryStore,
|
|
})
|
|
);
|
|
|
|
const keycloak = new Keycloak({ store: memoryStore });
|
|
----
|
|
Passing a custom scope value::
|
|
|
|
By default, the scope value `openid` is passed as a query parameter to {project_name}'s login URL, but you can add an additional custom value:
|
|
[source,javascript]
|
|
const keycloak = new Keycloak({ scope: 'offline_access' });
|
|
|
|
==== Installing middleware
|
|
|
|
Once instantiated, install the middleware into your connect-capable app:
|
|
|
|
In order to do so, first we have to install Express:
|
|
----
|
|
npm install express
|
|
----
|
|
|
|
then require Express in our project as outlined below:
|
|
|
|
[source,javascript]
|
|
----
|
|
const express = require('express');
|
|
const app = express();
|
|
----
|
|
|
|
|
|
and configure Keycloak middleware in Express, by adding at the code below:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.use( keycloak.middleware() );
|
|
----
|
|
|
|
Last but not least, let's set up our server to listen for HTTP requests on port 3000 by adding the following code to `main.js`:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.listen(3000, function () {
|
|
console.log('App listening on port 3000');
|
|
});
|
|
----
|
|
|
|
==== Configuration for proxies
|
|
|
|
If the application is running behind a proxy that terminates an SSL connection
|
|
Express must be configured per the link:https://expressjs.com/en/guide/behind-proxies.html[express behind proxies] guide.
|
|
Using an incorrect proxy configuration can result in invalid redirect URIs
|
|
being generated.
|
|
|
|
Example configuration:
|
|
|
|
[source,javascript]
|
|
----
|
|
const app = express();
|
|
|
|
app.set( 'trust proxy', true );
|
|
|
|
app.use( keycloak.middleware() );
|
|
----
|
|
|
|
==== Checking authentication
|
|
|
|
To check that a user is authenticated before accessing a resource,
|
|
simply use `keycloak.checkSso()`. It will only authenticate if the user is already logged-in. If the user is not logged-in, the browser will be redirected back to the originally-requested URL and remain unauthenticated:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get( '/check-sso', keycloak.checkSso(), checkSsoHandler );
|
|
----
|
|
|
|
==== Protecting resources
|
|
|
|
Simple authentication::
|
|
|
|
To enforce that a user must be authenticated before accessing a resource,
|
|
simply use a no-argument version of `keycloak.protect()`:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get( '/complain', keycloak.protect(), complaintHandler );
|
|
----
|
|
|
|
Role-based authorization::
|
|
|
|
To secure a resource with an application role for the current app:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get( '/special', keycloak.protect('special'), specialHandler );
|
|
----
|
|
|
|
To secure a resource with an application role for a *different* app:
|
|
|
|
[source,javascript]
|
|
app.get( '/extra-special', keycloak.protect('other-app:special'), extraSpecialHandler );
|
|
|
|
To secure a resource with a realm role:
|
|
|
|
[source,javascript]
|
|
app.get( '/admin', keycloak.protect( 'realm:admin' ), adminHandler );
|
|
|
|
Resource-Based Authorization::
|
|
|
|
Resource-Based Authorization allows you to protect resources, and their specific methods/actions,**** based on a set of policies defined in Keycloak, thus externalizing authorization from your application. This is achieved by exposing a `keycloak.enforcer` method which you can use to protect resources.*
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get('/apis/me', keycloak.enforcer('user:profile'), userProfileHandler);
|
|
----
|
|
|
|
The `keycloak-enforcer` method operates in two modes, depending on the value of the `response_mode` configuration option.
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'token'}), userProfileHandler);
|
|
----
|
|
|
|
If `response_mode` is set to `token`, permissions are obtained from the server on behalf of the subject represented by the bearer token that was sent to your application. In this case, a new access token is issued by Keycloak with the permissions granted by the server. If the server did not respond with a token with the expected permissions, the request is denied. When using this mode, you should be able to obtain the token from the request as follows:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'token'}), function (req, res) {
|
|
const token = req.kauth.grant.access_token.content;
|
|
const permissions = token.authorization ? token.authorization.permissions : undefined;
|
|
|
|
// show user profile
|
|
});
|
|
----
|
|
|
|
Prefer this mode when your application is using sessions and you want to cache previous decisions from the server, as well automatically handle refresh tokens. This mode is especially useful for applications acting as a client and resource server.
|
|
|
|
If `response_mode` is set to `permissions` (default mode), the server only returns the list of granted permissions, without issuing a new access token. In addition to not issuing a new token, this method exposes the permissions granted by the server through the `request` as follows:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get('/apis/me', keycloak.enforcer('user:profile', {response_mode: 'permissions'}), function (req, res) {
|
|
const permissions = req.permissions;
|
|
|
|
// show user profile
|
|
});
|
|
----
|
|
|
|
Regardless of the `response_mode` in use, the `keycloak.enforcer` method will first try to check the permissions within the bearer token that was sent to your application. If the bearer token already carries the expected permissions, there is no need
|
|
to interact with the server to obtain a decision. This is specially useful when your clients are capable of obtaining access tokens from the server with the expected permissions before accessing a protected resource, so they can use some capabilities provided by Keycloak Authorization Services such as incremental authorization and avoid additional requests to the server when `keycloak.enforcer` is enforcing access to the resource.
|
|
|
|
By default, the policy enforcer will use the `client_id` defined to the application (for instance, via `keycloak.json`) to
|
|
reference a client in Keycloak that supports Keycloak Authorization Services. In this case, the client can not be public given
|
|
that it is actually a resource server.
|
|
|
|
If your application is acting as both a public client(frontend) and resource server(backend), you can use the following configuration to reference a different
|
|
client in Keycloak with the policies that you want to enforce:
|
|
|
|
[source,javascript]
|
|
----
|
|
keycloak.enforcer('user:profile', {resource_server_id: 'my-apiserver'})
|
|
----
|
|
|
|
It is recommended to use distinct clients in Keycloak to represent your frontend and backend.
|
|
|
|
If the application you are protecting is enabled with Keycloak authorization services and you have defined client credentials
|
|
in `keycloak.json`, you can push additional claims to the server and make them available to your policies in order to make decisions.
|
|
For that, you can define a `claims` configuration option which expects a `function` that returns a JSON with the claims you want to push:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.get('/protected/resource', keycloak.enforcer(['resource:view', 'resource:write'], {
|
|
claims: function(request) {
|
|
return {
|
|
"http.uri": ["/protected/resource"],
|
|
"user.agent": // get user agent from request
|
|
}
|
|
}
|
|
}), function (req, res) {
|
|
// access granted
|
|
----
|
|
|
|
For more details about how to configure Keycloak to protected your application resources, please take a look at the link:{authorizationguide_link}[{authorizationguide_name}].
|
|
|
|
Advanced authorization::
|
|
|
|
To secure resources based on parts of the URL itself, assuming a role exists
|
|
for each section:
|
|
|
|
[source,javascript]
|
|
----
|
|
function protectBySection(token, request) {
|
|
return token.hasRole( request.params.section );
|
|
}
|
|
|
|
app.get( '/:section/:page', keycloak.protect( protectBySection ), sectionHandler );
|
|
----
|
|
|
|
Advanced Login Configuration:
|
|
|
|
By default, all unauthorized requests will be redirected to the {project_name} login page unless your client is bearer-only.
|
|
However, a confidential or public client may host both browsable and API endpoints. To prevent redirects on unauthenticated
|
|
API requests and instead return an HTTP 401, you can override the redirectToLogin function.
|
|
|
|
For example, this override checks if the URL contains /api/ and disables login redirects:
|
|
|
|
[source,javascript]
|
|
----
|
|
Keycloak.prototype.redirectToLogin = function(req) {
|
|
const apiReqMatcher = /\/api\//i;
|
|
return !apiReqMatcher.test(req.originalUrl || req.url);
|
|
};
|
|
----
|
|
|
|
==== Additional URLs
|
|
|
|
Explicit user-triggered logout::
|
|
|
|
By default, the middleware catches calls to `/logout` to send the user through a
|
|
{project_name}-centric logout workflow. This can be changed by specifying a `logout`
|
|
configuration parameter to the `middleware()` call:
|
|
|
|
[source,javascript]
|
|
----
|
|
app.use( keycloak.middleware( { logout: '/logoff' } ));
|
|
----
|
|
|
|
When the user-triggered logout is invoked a query parameter `redirect_url` can be passed:
|
|
|
|
[source]
|
|
----
|
|
https://example.com/logoff?redirect_url=https%3A%2F%2Fexample.com%3A3000%2Flogged%2Fout
|
|
----
|
|
|
|
This parameter is then used as the redirect url of the OIDC logout endpoint and the user will be redirected to
|
|
`\https://example.com/logged/out`.
|
|
|
|
{project_name} Admin Callbacks::
|
|
|
|
Also, the middleware supports callbacks from the {project_name} console to log out a single
|
|
session or all sessions. By default, these type of admin callbacks occur relative
|
|
to the root URL of `/` but can be changed by providing an `admin` parameter
|
|
to the `middleware()` call:
|
|
[source,javascript]
|
|
app.use( keycloak.middleware( { admin: '/callbacks' } );
|
|
|
|
==== Complete example
|
|
|
|
A complete example using the Node.js adapter usage can be found in https://github.com/keycloak/keycloak-quickstarts/tree/latest/service-nodejs/[Keycloak quickstarts for Node.js]
|