Uploaded image for project: 'Keycloak'
  1. Keycloak
  2. KEYCLOAK-8828

Authorization in keycloak-connect (NodeJS adapter) failed for confidential client without 'authorization' header

    Details

    • Sprint:
      Keycloak Sprint 15
    • Steps to Reproduce:
      Hide

      Without the fix, this page will fail (with access denied, because of promise rejection that says "No bearer in header". This example code is taken from the example of expressjs application in the keycloak-connect git repo. The only difference from the example in git repo is, try changing the client type to "confidential" in the keycloak admin (and of course update the keycloak.json in the expressjs project accordingly):

      app.get('/protected/resource', keycloak.enforcer(
      ['Default Resource:view']
      ), function (req, res) {
      res.render('index',

      { result: JSON.stringify(JSON.parse(req.session['keycloak-token']), null, 4), event: '1. Access granted to Default Resource\n' }

      );
      });

      Show
      Without the fix, this page will fail (with access denied, because of promise rejection that says "No bearer in header". This example code is taken from the example of expressjs application in the keycloak-connect git repo. The only difference from the example in git repo is, try changing the client type to "confidential" in the keycloak admin (and of course update the keycloak.json in the expressjs project accordingly): app.get('/protected/resource', keycloak.enforcer( ['Default Resource:view'] ), function (req, res) { res.render('index', { result: JSON.stringify(JSON.parse(req.session['keycloak-token']), null, 4), event: '1. Access granted to Default Resource\n' } ); });
    • Docs QE Status:
      NEW
    • QE Status:
      NEW

      Description

      When client type is confidential, and request from browser does not contain authorization header, grant-manager returns a promise rejection: https://github.com/keycloak/keycloak-nodejs-connect/blob/1980189ea2940b4addcf246f62cbe4b782b7120d/middleware/auth-utils/grant-manager.js#L141

      In reality however, if the user is already authenticated (to that client), the access token is already available in the request object (request.kauth.grant.access_token.token). We should use that.

      The fix I'm proposing is changing this:

      if (!bearerToken)

      { return Promise.reject('No bearer in header'); }

      To:

      if (!bearerToken) {
      if (request.kauth && request.kauth.grant && request.kauth.grant.access_token)

      { bearerToken = request.kauth.grant.access_token.token; }

      else

      { return Promise.reject('No bearer in header'); }

      }

      This fix will allow the use of this adapter to protect server-rendered pages by means of authorization (not just the basic .protect).

      Note: this issue still exists in 4.6.0.Final

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                pcraveiro Pedro Igor Silva
                Reporter:
                rakamoviz Cokorda Raka Angga Jananuraga
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: