Sharing authentication with another system to allow auto login in wiki.js

[ingarpedersen]

Is is possible for wiki.js to use authentication service in another system in such a way that a user who is authenticated in the other system can bypass the login page of wiki.js and be automatically logged in?
Typical use would be a user authenticates with the other system, then on a link is redirected to wiki.js, for many users it will seem strange to have to log in again since they have already logged into the other system.

Thanks

[DiegoColantonio]

I'm trying to make that build but I can't get it to work.

I have my own site, and I want access to be automatic for people who were logged into my site.

Any ideas??

THANKS!

[jcalfee]

I'm trying too, I have been looking at the code for about two days trying to figure out the best way. Kind of silly to do that when it may only take someone a few minutes to at the very least point us in the right direction. Or NO direction if it is not setup for that (that is perfectly fine too). Seems like the devs to not monitor discussions and have blocked the ability to make issues.

I have the session secret and the decrypted JWT but it is still a guess what the best way is. In the code in some cases like oauth2 it looks like it will pull key fields from the profile. I'm not sure if it will create or store it in a way that it will be used. Also, the call flow may be awkward, oath is designed to forward out of the wiki for authentication then have them come back. We just want them in.

The graphql can create users and manage their profile and log them in and fetch a JWT token. But what then? How does the outside server shove that JWT token back into the wiki so they can just go right in? I see references to Cookies and cookies can't cross domains.

Probably best to just to fork it and do something like piggy back on the session library with ones own route to initialize it..

It would be cool if there were a discord channel or something. I'll post again when I have something just hope it is not a hack.

[jcalfee]

I have had some success. This is what I have so far: #5149 (comment)

[ingarpedersen]

In our case we're not using oauth2, so I guess that won't help us, but good work so far...
If you get it all working we might look at it again and see if we can adapt it to our solution.

[jcalfee]

I compared a few authentication modules and the ones I looked at were very similar and basically the same pattern (abstract details handled in passport). So it may not matter matter too much which one.

I decided the re-check using a oauth2 refresh token was not worth it. Long story short, the auth and renew keys are not stored in the JWT session or database already and are simply discarded. It really is not technically necessary in my case to store the tokens since I can do the renew check server-to-server. Also, storing tokens has implications on the auth server's security model: the JWT session is only signed and not encrypted so trying to take the "renew" token route has security considerations, it should instead be encrypted and kept in another cookie. Also, the "init" in the auth modules (where the refresh token first shows up) do not easily have a way to add something to the JWT session and it is really burdensome to keep changing the wiki's server code when webpack restarts (crashes in my opinion) every change. But again, server-to-server is fine for my purpose so this need not involve the client or concern the auth server.

So, I simply copied the module (oauth2 in my case) and suffixed the name, id, etc with our brand and changed the database so my test accounts started using the new module in place of the original. I added my own property to the module "recheck url" ..

defination.yml

  recheckURL:
    type: String
    title: Subscription recheck URL
    hint: Recheck account every Administration > Security > Login > Token Expiration.
    order: 6

Then I was able to make a small patch to the core/auth.js file to call my custom method "recheck" in the authentication module. There I make a direct API call to recheck the login and fetch changed updateable fields like "name" or "email". And of course, it can always return false to invalidate the JWT and sent them to Guest in my case (or you could use logoutUrl instead in the patch). I use the same "Client Secret" to HMAC sign and validate the re-check and simply pass the email (must be unique) to know what user to recheck. In auth/core.js with this patch, got it to take advantage of the configurable token review period under security where I left it at 1m to work everything out.

v2.5.277

+++ b/server/core/auth.js
@@ -114,10 +114,10 @@ module.exports = {
       if (err) { return next() }
       let mustRevalidate = false
 
-      // Expired but still valid within N days, just renew
+      // About to expired but still valid within N days, just renew
       if (info instanceof Error && info.name === 'TokenExpiredError') {
         const expiredDate = (info.expiredAt instanceof Date) ? info.expiredAt.toISOString() : info.expiredAt
-        if (DateTime.utc().minus(ms(WIKI.config.auth.tokenRenewal)) < DateTime.fromISO(expiredDate)) {
+        if (DateTime.utc().plus(ms(WIKI.config.auth.tokenRenewal)) > DateTime.fromISO(expiredDate)) {
           mustRevalidate = true
         }
       }
@@ -140,14 +140,31 @@ module.exports = {
         }
       }
 
+      async function recheckProfileUpdate() {
+        const providerInfo = _.get(WIKI.auth.strategies, user.providerKey, {})
+        if (providerInfo.recheck) {
+          WIKI.logger.info(`Recheck user_id ${user.id}`)
+          const profile = await providerInfo.recheck(user, providerInfo.config)
+          if (profile.success !== true) {
+            // res.redirect(providerInfo.config.logoutURL)
+            user = null // Change to Guest
+            mustRevalidate = false
+          } else {
+            return profile.update
+          }
+        }
+      }
+
       // Revalidate and renew token
       if (mustRevalidate) {
         const jwtPayload = jwt.decode(securityHelper.extractJWT(req))
         try {
           const newToken = await WIKI.models.users.refreshToken(jwtPayload.id)
+
           user = newToken.user
           user.permissions = user.getGlobalPermissions()
           user.groups = user.getGroups()
+          Object.assign(user, await recheckProfileUpdate())
           req.user = user
 
           // Try headers, otherwise cookies for response

...

server/modules/authentication/oauth2-[brand]/authentication.js

  // + new function after "init"
  // yarn install create-hmac
  async recheck(user, conf) {
    const body = {
      email: user.email,
      providerId: user.providerId,
      clientId: conf.clientId
    }

    const sign = '[BRAND]_RECHECK' + JSON.stringify(body)
    const sig = createHmac('sha256', conf.clientSecret).update(sign).digest('base64')

    const userRecheck = await request({
      uri: conf.recheckURL,
      method: 'post',
      json: true,
      headers: { 'hmac-256-sig': sig },
      body
    })

    if (userRecheck.success !== true) {
      WIKI.logger.info(`User providerId ${user.providerId} recheck failed`, userRecheck)
      return {success: false}
    }

    const profile = userRecheck.user

    const same = (
      user.email === _.get(profile, conf.emailClaim) &&
      user.name ===  _.get(profile, conf.displayNameClaim, '???')
    )

    if(same) {
      return {
        success: true,
        update: {}
      }
    }

    await WIKI.models.users.processProfile({
      providerKey: user.providerKey,
      profile: {
        ...profile,
        id: user.providerId,
        displayName: _.get(profile, conf.displayNameClaim, '???'),
        email: _.get(profile, conf.emailClaim)
      }
    })

    return {
      success: true,
      update: {
        email: user.email,
        name: user.name
      }
    }
  },

Custom recheck route (/api/userrecheck) in the authentication server

const clientSecret = 'ssh-password'

/**
 * Js.requarks/wiki is patched to check this method after its JWT expiration
 * time in Administration > Security > Login > Token Expiration.
 */
module.exports.recheck = function(request, response) {
  const sign = '[brand]_RECHECK' + JSON.stringify(request.body)
  const sig = createHmac('sha256', clientSecret).update(sign).digest('base64')
  const checkSig = request.headers['hmac-256-sig']

  // console.log({sign, sig, checkSig})
  if(sig !== checkSig) {
    // 401 Unauthorized
    return response.status(401).json({error: 'Unauthorized header: hmac-256-sig'})
  }

  // const {email, providerId, clientId} = request.body
  // console.log(`User recheck user ${email} providerId ${providerId} sig ${sig} clientId ${clientId}`)

  response.json({
    success: true,
    user: {
      name: 'Recheck Name2',
      email: '[email protected]'
    }
  })
}

The wiki does not immediately reflect a change in name or email everywhere. Small price to pay for now though, at least I have it working.

[jcalfee]

Because the clientSecret was already used in the Bearer strategy (server-to-server) in the authentication process, I replaced hmac-256-sig above with a simple header Authorization: Bearer ${clientSecret}.

It would be better to avoid this "refresh" patch in favor of storing the access and refresh tokens on the wiki's side:

• this would preserve information in the tokens
• would preserve the security gained by prior authentication steps
• would be standards complaint

I did not use passport's server-side sessions for this because I was concerned that scaling up the wiki processes (load balancing for example) would put the user's authentication steps at risk of hitting a node that did not have a required token. Those should probably be stored in the database instead. I find it good practice to encrypt data like this with a shared secret unique per NODE_ENV which decreases the attack vector (a db compromise alone is not enough) and makes the databases easier to share across environments like dev, test, stage, production.