Hi!

I'm getting this message "This webpage has a redirect loop" after the success login. I've narrow the problem in this file "grant-manager.js".
var verify = crypto.createVerify('RSA-SHA256');
verify.update( token.signed );
if ( ! verify.verify( this.publicKey, token.signature, 'base64' ) ) {
return;
}
the problem is that the verify function fails so, the function validateToken returns, so it try again over and over.

I'm using keycloak 1.0.1 (latest version didn't work for me) and the latest version of keycloak-nodejs

Thanks in advance.

Using Express 4.xx is fine. However, the sample code breaks if using 3.xx.
I found out this by trying to use Keycloak in a Sails project without any luck because Sails uses Express 3.xx.
The particular version of Express is "3.16.0"

We need to create an overview of all of the features that the Node.js Connect adapter provides so we can determine if it can be replaced by alternatives.

I've been looking at below to integrate with Node.js Restify application.

http://keycloak.github.io/keycloak-nodejs/connect/index.html

When do you plan to release the stable version of nodejs adaptor?

I also tried to integrate with Restify but it seems to hang without any callback with infinite loop on the browser. This happens when I put in protect() method for .get request. I suppose it's due to requirement of connect middleware. Basically the code that I have is:

server.get({url: '/hb'}, kc.protect(), function(req, res) {
res.send("ok");
});

Any of your help would be greatly appreciated.

Dear keycloak-connect maintainers,
Thank you for your contribution to the open-source community.

This issue was automatically created to inform you a new version (16.1.1) of keycloak-connect was published without a matching tag in this repo.

Our service monitors the open-source ecosystem and informs popular packages' owners in case of potentially harmful activity.
If you find this behavior legitimate, kindly close and ignore this issue. Read more

Re-enable and fix the tests that that have been skipped in #427.

Describe the bug

Currently the realmUrl and other URLs are constructed by prefixing them with the auth-server-url from the config file. The auth-server-url should only be uses to get the openid-configuration:

/realms//.well-known/openid-configuration

In the response of this request you can get all necessary urls (eg logout, autohorization-endpoint,...)

Version

12

Expected behavior

Get all openid related endpoints from /realms//.well-known/openid-configuration

Actual behavior

How to Reproduce?

No response

Anything else?

No response

Describe the bug

The logoutUrl function on the Keycloak prototype takes to parameters. The first one redirectUrl is required, whilst the idTokenHint is an optional parameter (per the TS types).

However – if the idTokenHint is not provided, the redirectUrl is not included, because of this check 👇

if (redirectUrl && idTokenHint) {
  url.searchParams.set('id_token_hint', idTokenHint)
  url.searchParams.set('post_logout_redirect_uri', redirectUrl)
}

Version

15.1.1 (server) - 19.0.1 (keycloak-connect)

Expected behavior

When calling the logoutUrl method from the Keycloak prototype, passing a redirectUrl I expect the redirectUrl to be included in the logoutUrl returned. Regardless of whether or not the idTokenHint is provided.

Actual behavior

If no idTokenHint is passed to the Keycloak.prototype.logoutUrl method the redirectUrl is not appended either. It's either idTokenHint+redirectUrl or nothing at all.

How to Reproduce?

const kc = new Keycloak(...)

// this one will include the redirectUrl
kc.logoutUrl('https://where.to.go', 'id123')

// this one won't include the redirectUrl, because of the missing id token hint
kc.logoutUrl('https://where.to.go')

Anything else?

No response

Description

When using CNAMEs to point to the Keyclaok server, the JWT created has in the iss field the CNAME. As the KC Server can be react over both addresses, the auth-server-url field of the Config must take this into account. In the code line

Proposal
Type for backwards compatibility:

type auth_server_url_type: string | string[]

Usgage:

let iss = new URL(token.content.iss)
if ((typeof this.config.realmUrl) === "string") {
  // Use like until now
} else if (Array.isArray(this.config.realmUrl) {
  if (this.config.realmUrl.includes(iss.host) && (iss.pathname === ''/realms/' + this.config.realm) // Accept/Reject
} else {
  // Error (the Config class constructor should check this)
}

Discussion

No response

Motivation

No response

Details

No response

Description

Based on keycloak documentation on java adapter, here

There is an option to activate HTTP basic authentication feature.

"enable-basic-auth" : false

Description of the configuration,

OPTIONAL. This tells the adapter to also support basic authentication. If this option is enabled, then secret must also be provided. The default value is false.

The "Basic" HTTP authentication allow us to transmits credentials as user ID/password pairs, encoded using base64 in the authorization request headers, like this.

Authorization: basic dXNlcm5hbWVrdTpwYXNzd29yZGt1

It seems keycloak nodejs adapter does not have this option yet, would be great to see this feature added in the future.

Discussion

No response

Motivation

No response

Details

No response

Describe the bug

In a corporate cloud environment we use ipv6 addresses. When the redirect uri is not defined keycloak-connect create a redirect-ui based on the request host for the logout. When the host is an ipv6 address, then parsing out the port number is not working right. It adds part of the ipv6 address instead of the real port number.

Version

19

Expected behavior

When the host of the request is an ipv6 address like [2001:db8:4006:812::200e]:8080 then the generated post_logout_redirect_uri should be [2001:db8:4006:812::200e]:8080

Actual behavior

Now the generated post_logout_redirect_uri is [2001:db8:4006:812::200e]:db8

How to Reproduce?

It is hard to reproduce, because it is not a normal use case that you use ipv6 ip address for a website. I think in out case it is caused by some kind of proxying inside the cloud environment. But it is a simple parsing problem. The port parsing for ipv6 should be different. Something like this.

let getPort = (url) => {
    let res;
    if (isIpv6Address(url)) {
        res = url.split(']');
        res = res[1].split(':');
    } else {
        res = url.split(':');
    }
    return res[1] || '';
} 

Anything else?

No response

Describe the bug

When validating a user-agent token (created via a public client) from a bearer-only client (backend application) that use different keycloak hostnames, the validation fails with error invalid token (wrong ISS).

Using the external, public url for the keycloak server in the backend application avoids this issue.

The bug also occurs when setting the frontend URL, which changes the authorization_endpoint to the public URL, while maintaining the request URL in the token_endpoint advertisement.

Version

15.0.2

Expected behavior

Given the proposal of the default hostname providers and the frontend url configuration, the nodejs client should accept tokens with ISS that is different from the current realm url.

Actual behavior

No response

How to Reproduce?

No response

Anything else?

I found the specific code to be here:

Hello,

Please improve redirectURL script on forceLogin function to broaden compatibility with other framework beside Express such as Fastify. Currently, it uses request.hostname to retrieves hostname and request.headers.host to retrieves port number. Unfortunately, it won't work on Fastify Framework because Fastify will assigns same value to request.headers.host and request.hostname (host_name:port_number).

I hope you could retrieves hostname from request.headers.host than request.hostname, thank you

Original

Improvement

  let headerHost = request.headers.host.split(':');
  let host = headerHost[0];
  let port = headerHost[1] || '';

For example, my redirect url will become:
localhost:8080/realms/myrealm/protocol/openid-connect/auth?client_id=spc-client&state=ca6cc925-acf7-474b-8057-46ba40e35f88&redirect_uri=http%3A%2F%2Flocalhost%3A3000%3A3000%2Faltair%3Fauth_callback%3D1&scope=openid openid profile email&response_type=code

Describe the bug

chromedriver is being installed in my production builds with pnpm and turborepo. I can see that it's listed in optionalDependencies but it seems to be installed regardless and I can't seem to deselect it or create an override in pnpm.

Could this be safely moved to devDependencies?

pnpm-lock.yaml

  /[email protected]:
    resolution: {integrity: sha512-3aTU3m/hA9to6NhC1pLK6Rv/9zqJuvmX5J5C4LkKXF64ejQk/nlUnPw2hrBky+s6eJneFQ/sCWf4OSNGsenAYw==}
    engines: {node: '>=14'}
    dependencies:
      jwk-to-pem: 2.0.5
    optionalDependencies:
      chromedriver: 119.0.1
    transitivePeerDependencies:
      - debug
      - supports-color
    dev: false

Version

22.0.5

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Anything else?

No response

Describe the bug

After starting the docker image and adding the realm via the import button and uploading nodejs-example-realm.json, I can login but I cannot access the protected route and receive "Access Denied".

Version

Keycloak 17.0.1

Expected behavior

Result and Access Granted Event

Actual behavior

Access denied

How to Reproduce?

Add the realm via the import button and uploading nodejs-example-realm.json

npm link ../
npm install
npm start

Open the browser at http://localhost:3000/ and login with username: 'user', and password: 'password'.

click protected route

Anything else?

This is a duplicate of #310 which was closed. However, I think the example configuration (nodejs-example-realm.json) should be adapted so it works without further configuration.

We need to compare the features of the Node.js Connect adapter with the alternative we're intending to recommend and ensure that all features are covered. If there are missing features we need to come up with a strategy to migrate users of these features.

Description

Certain servers (AWS: block nouseragent-header in Web ACLs ) block requests that are missing user-agent headers. Due to this, it's not possible to retrieve JWKs or exchange code with access tokens.

Discussion

No response

Motivation

Due to security policies of cloud providers e.g., AWS, Azure they can block requests which don't have user agent headers.

Details

I would like to add user agent headers wherever requests are sent to keycloak servers

Description

Description
The bearer token seems to be expected to be in Authorization Header only. It is a point to note that not all applications are conformed to use of Authorization Headers. For example, some applications, spring boot apps use both authorization headers and the url request query parameter access_token, some even cookies.

Discussion

#349

Motivation

The current situation limits flexibility and interoperability of applications that communicate together via Rest API,Solving this problem will make it easier for developers to specify areas to look for the token that suites their specific needs. Otherwise It can be a lot of work having to rewrite application that depends on the application based node keycloack to force them to use Authorization headers for bearer tokens.

Details

This can be implemented as configurations which allows a developer to specify part of the request where the token should be extracted from, and that can be

1. The name of the header, for some they could want to use custom headers, the default could be Authorization.
2. Request query parameter
3. cookies

Describe the bug

The grant manager class has the signature algorithm fixed at RSA-SHA256. You can see that here.

Keycloak allows us to change that algorithm. If I do that, the validate function will reject every token, even if it is valid, because it will attempt to use the wrong algorithm.

Version

keycloak: 15.0.2
keycloak-connect: 15.0.2

Expected behavior

Keycloak correctly validates tokens signed with different algorithms

Actual behavior

Keycloak rejects all tokens except those signed with RSA-SHA256

How to Reproduce?

Change access token signature algorithm to anything other than RS256, generate a token and attempt to validate using this lib.

Anything else?

A good fix would be to allow the algorithm to be configurable, and have RSA-SHA256 as the default value to avoid a breaking change.

Describe the bug

After updating keycloak-connect to 17.0.0 in my express-based project, the protect function is always returning "Access denied" even if the user has the given role. This was working with version 15.0.2 (the version I was using before).

app.post('/my-api/abos-custom', keycloak.protect('reader-role'), serviceCalls.getData);

Update:
I think that the problem has something to do with the realmPublicKey in the the Config object which is used to init the keyCloak object.

Version

17.0.0 (Quarkus)

Expected behavior

Should not return "Access denied" if the user has the given role.

Actual behavior

Function returns always "Access denied".

How to Reproduce?

Anything else?

Where can I find the documentation of the API for version 17.0.0?

Describe the bug

After starting the docker image and adding the realm via the import button and uploading nodejs-example-realm.json, I can login but I cannot access the protected route and receive "Access Denied".

Version

Keycloak 15.1.0

Expected behavior

Result and Access Granted Event

Actual behavior

Access denied

How to Reproduce?

docker run -p 8080:8080 -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin jboss/keycloak

Add the realm via the import button and uploading nodejs-example-realm.json

npm link ../
npm install
npm start

Open the browser at http://localhost:3000/ and login with username: 'user', and password: 'password'.

click protected route

Anything else?

No response

Description

In Keycloak 19 was added support for client_id as described in the OIDC RP-Initiated specification.
More details could be found here keycloak/keycloak#12002 (comment)

At this moment the library does not offer support for setting the client_id in the logout URL and the post_logout_redirect_uri query param is set only if idTokenHint function param is set.

Discussion

No response

Motivation

The library should match the Keycloak Server capabilities.

Details

The logout function should look like this

Keycloak.prototype.logoutUrl = function (redirectUrl, idTokenHint) {
    const url = new URL(this.config.realmUrl + '/protocol/openid-connect/logout')

    url.searchParams.set('client_id', this.config.clientId)

    if (redirectUrl) {
      url.searchParams.set('post_logout_redirect_uri', redirectUrl)
    }
 
    if (idTokenHint) {
      url.searchParams.set('id_token_hint', idTokenHint)
    }

    return url.toString()
}

A part of the above implementation is already done #420.

Describe the bug

Steps to reproduce:

1. Use keycloak.protect() to protect a path like eg. here https://github.com/keycloak/keycloak-quickstarts/blob/99725dc62f0bca92857ff2d947829611517ed63e/nodejs/resource-server/app.js#L16
2. Use the app to generate a valid token that has, however, some subtle problem like being generated for localhost instead of 127.0.01

What should happen:

• The logged error message should point to the specific cause of failure. Like "Grant validation failed. Reason: invalid token (wrong ISS)"

What happens instead:

• The logged error message is just "Could not obtain grant code error"

Version

22.0.1

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Anything else?

No response

Describe the bug

The KeycloakConfig typedef is defined here:

However in Keycloak 18, the config JSON is being generated as such:

Providing the public-client parameter to the KeycloakConfig object causes an error. Suggest updating the typedef to:

  interface KeycloakConfig {
    'confidential-port': string|number
    'auth-server-url': string
    'resource': string
    'ssl-required': string
    'bearer-only'?: boolean
    realm: string
    'public-client': boolean;
  }

Version

18.0.2

Expected behavior

Expectation is that KeycloakConfig contains all attributes that can be generated by the Keycloak server

Actual behavior

KeycloakConfig is missing a parameter

How to Reproduce?

Try to add the public-client parameter to a KeycloakConfig results in a compilation error

Anything else?

No response

Describe the bug

The checkSso functionality was introduced a while ago in the Node.js adapter. Such functionality is problematic considering that it lacks a validation mechanism, and fixing it would require significant effort from our team.

Evaluating the impact on users, it would be better if we managed to deprecate this functionality displaying a warning int the console people can have more time finding a better alternative.

Version

18.0.0

Describe the bug

When using the Keycloak-connect npm package, there is a function to generate the logout url: keycloak.logoutUrl.
According to the typescript types, it accepts 2 parameters:

• redirectUrl: string (mandatory)
• idTokenHint?: string (not-mandatory)

Calling this method with only the mandatory parameter does not gives the expected output.

Version

20.0.2

Expected behavior

When only the mandatory parameter redirectUrl is passed to the function, the generated logout url should contain it.

Actual behavior

The redirectUrl parameter does not get added to the generated logout url unless the optional idTokenHint is passed as well. In this case, both are added to the generated url.

How to Reproduce?

Get a configured setup of keycloak-connect and call the method keycloak.logoutUrl with only 1 parameter. In that case, the parameter value does not get found in the generated logout url

Anything else?

I'll create a PR to fix this

Good night, i'm using keycloak-nodejs adapter. I can access to keycloak using expressjs, but i need to send request from client side too.

The keycloak-nodejs can intercept all client side request to access to a .war restfull service?

Here is a image which represents the question. https://docs.google.com/drawings/d/1zPRtS_-pPKI3fuAgkRvTzXfBODYFzEh7DCfnOf8krmc/edit?usp=sharing

Describe the bug

In the package.json file following dependency is defined with Github source

"keycloak-admin-client": "bucharest-gold/keycloak-admin-client"

but this repository is either not present or not public. This is breaking the example.

Version

16.0.0-dev

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Anything else?

No response

Description

Since this library is deprecated I would like to propose one of the possible alternatives => jose
It contains quite useful functions: createRemoteJWKSet and jwtVerify as described here: https://github.com/panva/jose/blob/main/docs/functions/jwks_remote.createRemoteJWKSet.md#function-createremotejwkset

Example verification with jose looks like this:

import { JWTPayload, createRemoteJWKSet, jwtVerify } from "jose";

const auth_server_url = "http://keycloak.localhost:8080";
const jwks = createRemoteJWKSet(new URL(`${auth_server_url}/realms/${realmName}/protocol/openid-connect/certs`));
const { payload } = await jwtVerify(token, jwks); // this line will throw on invalid token
console.log(payload.sub);

jose automatically fetches public keys from endpoint if previous ones are not valid.

The JSON Web Key Set is fetched when no key matches the selection process

Jose library seems to cover significant part of keycloak-nodejs-connect functionality. I already using it in my app and DX is even more enjoyable. I have more control and can create express middleware myself, or integrate it in any kind of app bcs it is not tightly coupled to expressjs.

@jonkoops @abstractj I would really appreciate your review about using jose, seems like it can be recommended as keycloak-nodejs-connect alternative or at least one of alternatives. In any case would be very helpful to hear your thoughts on it, whether you think it is good replacement or not. Tagging both of you since you guys seem to be active ones in this repo from maintainers.

Btw, also, as I checked another library named jose is used under the hood in keycloak Java source code too.

Description

It seems this repository and related npm package should be marked as deprecated, according to this article : https://www.keycloak.org/2022/02/adapter-deprecation.

Discussion

No response

Motivation

Let users known this is deprecated

Details

No response

Describe the bug

The token type in keycloak.d.ts is not completed so when i write for example
req.token.content i have this error
Property 'content' does not exist on type 'Token'.

Version

16.1.0

Expected behavior

I would expect the Token type to be something like

The type for a token is :

interface Token {
    isExpired(): boolean
    hasRole(roleName: string): boolean
    hasApplicationRole(appName: string, roleName: string): boolean
    hasRealmRole(roleName: string): boolean
    content: <anythinghere>
    ...
  }

Actual behavior

The type for a token is :

interface Token {
    isExpired(): boolean
    hasRole(roleName: string): boolean
    hasApplicationRole(appName: string, roleName: string): boolean
    hasRealmRole(roleName: string): boolean
  }

How to Reproduce?

No response

Anything else?

No response

Description

Function postAuth can't redirect to full cleanUrl.

Because we have an app name after the hostname and current version redirect with error.

Our url:
http://host-name/app-name/path

Redirect url in current version:
http://host-name/path

Add generation for redirect as in protect.js

const host = request.hostname
const headerHost = request.headers.host.split(':')
const port = headerHost[1] || ''
const protocol = request.protocol

const redirectUrl = protocol + '://' + host + (port === '' ? '' : ':' + port) + cleanUrl

Discussion

No response

Motivation

No response

Details

#391

Description

For users it would be handy to add warning with alternatives to docs here. Perhaps link to "nodejs adapter deprication update" post would do the job.

At npm:

Warning This package is deprecated and will be removed in the future. We will shortly provide more details on removal date, and recommended alternatives.

To improve the statement I suggest provide more details at least link to this thread (for me it took quite some time to find this discussion with handy tips/alternatives from community).

Details

For more details on topic of deprication read this related discussion.

Once we have our migration guide in place we need to set a hard deprecation date for the Node,js Connect adapter. After this date the adapter will no longer be officially supported.

Describe the bug

We need to define CA trust for our adapter when it fetches new public keys. Currently this is possible in an arcane way using environment variables but requires detailed knowledge on how to do that.

A natural way to configure that would be with some sort of “ca:” property in KeyCloakConfig.

Version

15.0.2-redhat-00001

Expected behavior

It should be easy to supply trust for key fetch requests.

Actual behavior

We are using NODE_EXTRA_CA_CERTS instead. It is suboptimal and creates a few problems when running CI/CD and when the node process should have different trust roots for different endpoints.

How to Reproduce?

No response

Anything else?

No response

Once we have settled on a recommended alternative and covered all the edge cases and missing features we need to write a migration guide for users of the Node.js Connect adapter.

Once we have passed the final deprecation date of the Node.js Connect adapter we will have archive the corresponding GitHub repository and update the README to show the final deprecation notice.

Please check: keycloak/keycloak#9818

Description

The TypeScript type definitions are out of sync with the JavaScript code which can make it difficult to use, especially for new users. Ideally these should be updated to be in sync with JavaScript and any contributions should require updating these.

This was previously raised in Jira: KEYCLOAK-13841 and KEYCLOAK-14578.

Discussion

No response

Motivation

TypeScript is very popular and the community has been trying to update these type definitions (#245, #250, #289, #290, #291), but most require review, especially given that there are a few now.

Details

No response

Description

The Keycloak issue keycloak/keycloak#10885 adds support for OIDC RP-Initiated logout to Keycloak. There are some changes in the logout logic, which caused some tests to fail in keycloak-nodejs-connect.

This task is to adjust with latest Keycloak main once the OIDC RP-Initiated logout is updated in Keycloak. The PR for keycloak-nodejs-connect can be merged after this PR to keycloak-main is merged: keycloak/keycloak#10887

Discussion

No response

Motivation

No response

Details

No response

Description

When there is no bearer token present in the authentication header. The adapter should look through cookies to see if a bearer token is present there. If a bearer token is present, the adapter should use that one, instead of throwing a No bearer in header error.

Discussion

No response

Motivation

When the bearer token is stored in a cookie, the adapter can't find the bearer token. Making it throw a 'No bearer in header' error.
I would like to use a cookie to store my bearer token instead of putting it in a header. While being able to retrieve permissions from keycloak.

Details

I'm willing to make a PR to address this.

Description

Reviving the following old PR as I'm hitting the same issue:
#97

https://issues.redhat.com/browse/KEYCLOAK-5771?workflowName=GIT+Pull+Request+workflow+&stepId=4

I need to use an async GuardFn for my application.

New PR is here:
#355

Discussion

No response

Motivation

No response

Details

No response

Once we have passed the final deprecation date of the Node.js Connect adapter we will have to update the deprecation message on NPM to indicate the package is no longer supported.

Description

When using keycloak as an authorization service. We need to implement policy enforcer point in services.
For nodejs, Im using keycloak-connect to setup the middleware.
And I realize that it not support the policy-enforcer configs in the kkeycloak.json file. So I need to implement it by writing code.
I think it will be very nice if the keycloak-connect adapter supports the policy-enforcer configs in json file.

Discussion

No response

Motivation

No response

Details

As the authorization service documentation, we can config the enforcer like this in keycloak.json file

  "policy-enforcer": {
    "user-managed-access" : {},
    "enforcement-mode" : "ENFORCING",
    "paths": [
      {
        "path" : "/someUri/*",
        "methods" : [
          {
            "method": "GET",
            "scopes" : ["urn:app.com:scopes:view"]
          },
          {
            "method": "POST",
            "scopes" : ["urn:app.com:scopes:create"]
          }
        ]
      },
      {
        "name" : "Some Resource",
        "path" : "/usingPattern/{id}",
        "methods" : [
          {
            "method": "DELETE",
            "scopes" : ["urn:app.com:scopes:delete"]
          }
        ]
      },
      {
        "path" : "/exactMatch"
      },
      {
        "name" : "Admin Resources",
        "path" : "/usingWildCards/*"
      }
    ]
  }
}

Description

It would be a good idea to add a callback for the error page on the Keycloak middleware.

For example, the middleware setup could look like this and it will be possible to create your own 401 Unauthorized pages.

app.use(keycloak.middleware({
  logout: '/logout',
  admin: '/',
  error: '/error'
}));

Discussion

No response

Motivation

On our project with my team, we are using node.js and Keycloak.
For the unauthorized page, we had some issues editing it.

Details

No response

Description

It seems that the last update to coveralls was done ~3 years ago via travis CI.
This repository new-module-starter has a CI config that can help with that.
( This repository is a kind of implementation of some development recommendations from Node.js Reference Architecture ).

Discussion

No response

Motivation

No response

Details

No response

Describe the bug

You deprecated this library, but you haven't updated the official Keycloak documentation here:
https://www.keycloak.org/docs/latest/securing_apps/#_nodejs_adapter

This is confusing and time-consuming and worst of all can be missed.

Version

21

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Anything else?

No response