redwoodjs / redwood

The App Framework for Startups
https://redwoodjs.com
MIT License
16.99k stars 973 forks source link

[Bug?]: "jwt not active" for azure ad auth on local machine #9963

Open tilmann opened 6 months ago

tilmann commented 6 months ago

What's not working?

Problem There seems to be a problem with the clock tolerance for azure tokens while verifying the jwt.

This leads to this error while developing on an irregular basis:

image

Solution There is an option in jwt.verify called clockTolerance. This was discussed here as well: https://github.com/nextauthjs/next-auth/pull/3071

image

It would be helpful to either set the clockTolerance as an option. (currently only issuer is allowed) or set this to a standard value like 10 seconds.

From jwtVerifier.ts:

export const verifySignature = ({
  payload,
  secret = DEFAULT_WEBHOOK_SECRET,
  signature,
  options,
}: {
  payload: string | Record<string, unknown>
  secret: string
  signature: string
  options: VerifyOptions | undefined
}): boolean => {
  try {
    if (payload === undefined || payload?.length === 0) {
      console.warn('Missing payload')
    }

    if (options?.issuer) {
      jwt.verify(signature, secret, { issuer: options?.issuer }) as Record<
        string,
        unknown
      >
    } else {
      jwt.verify(signature, secret) as Record<string, unknown>
    }

    return true
  } catch {
    throw new WebhookVerificationError()
  }
}

How do we reproduce the bug?

The reproduction would be a redwood project with azure auth configured and then adjusting the local clock a few seconds to the past.

What's your environment? (If it applies)

System:
    OS: macOS 14.2.1
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.17.1 - /private/var/folders/y2/w6wgm3gs4p9bb6rgmfc9dwpc0000gn/T/xfs-57a09134/node
    Yarn: 3.2.3 - /private/var/folders/y2/w6wgm3gs4p9bb6rgmfc9dwpc0000gn/T/xfs-57a09134/yarn
  Databases:
    SQLite: 3.43.2 - /usr/bin/sqlite3
  npmPackages:
    @redwoodjs/auth-azure-active-directory-setup: 6.4.2 => 6.4.2 
    @redwoodjs/cli-storybook: 6.4.2 => 6.4.2 
    @redwoodjs/core: 6.4.2 => 6.4.2

Are you interested in working on this?

dthyresson commented 6 months ago

Hi @tilmann and thanks for surfacing this issue.

The verifier code you showed is for webhooks — but should consider updating as well.

The decoder for Azure AD is here: https://github.com/redwoodjs/redwood/blob/d2b7f7fb4d70243616d9f9dcf7c5bfe1e6a4981f/packages/auth-providers/azureActiveDirectory/api/src/decoder.ts#L55

Would a sensible default (5 seconds. 20?) and then an envar to customize be a solution?

tilmann commented 6 months ago

Hey @dthyresson,

thanks for the fast reply and the suggested solution. In https://github.com/nextauthjs/next-auth/pull/3071 the team decided for 10s. I would just go with the same value. I think you have a better understanding if we even need the envar. I would hope that this solves the problem for everyone.

I am currently running my system 5s "in the future" and the error is gone.

dthyresson commented 6 months ago

@tilmann Thanks for the next auth link, I confess I didn't look at it before -- and good to know that Azure AD has this known issue with timing tolerance. 10 seconds seems like the sensible default and it appears nextauth had a way to set a custom amount too, so some envier or setting feels proper.

What's the best way for us to test and confirm a fix? Would you be able to test a canary v7 release with an update?

@Tobbe If we modify the Azure auth package, could we publish just an update to that one package -- or would we need to wait from a new v7 rc?

tilmann commented 6 months ago

Happy to test a published version. We are on v6 but I need to upgrade our Codebase at one point in time anyway.

larsvaehrens commented 5 months ago

We use Azure AD B2C and have been having this issue for more or less a year in our dev environments. Our org controls the clock setting/synchronization in Windows, so the only way for us to reproduce it is to let the clock go out of sync by leaving the computer running for several days, but it is quite reliable (and annoying when it does happen 😅).