To clarify: you intend to use Netlify Identity as your authentication provider, but not deploy your api on Netlify.
This might be problematic because of the way Netlify Identity handles the JWT and its decoding – especially in production vs dev.
While the web side may be talking to Netlify Identity via the widget, the api side relies on something else.
See: redwood/packages/api/src/auth/decoders/netlify.ts at 53349fd121f9198a8fdb5c0217cec8c4f8b6badd · redwoodjs/redwood · GitHub
export const netlify = (token: string, req: { context: LambdaContext }) => {
// Netlify verifies and decodes the JWT before the request is passed to our Serverless
// function, so the decoded JWT is already available in production.
if (process.env.NODE_ENV === 'production') {
const clientContext = req.context.clientContext as NetlifyContext
return clientContext?.user || null
} else {
// We emulate the native Netlify experience in development mode.
// We just decode it since we don't have the signing key.
return jwt.decode(token)
}
}
In development mode, the decoder simply decodes the JWT and will then return the decoded claims such as sub (subscriber) which is the user id.
Note: What is important here is that in dev, the token is not verified. It’s signature is not checked, nor its expiration, etc.
But, in production, the decoder relies on the fact that Netlify’s implementation decodes and verifies the token for you and returns a user with those claims from the JWT.
This is likely why you get the
Cannot read property ‘sub’ of null
because the user is null because you don’t have access to the req.context.clientContext that Netlify provides when not deploying your api to Netlify.
I can think of some creative ways around this – and can discuss – but perhaps you may consider a different auth provider given it isn’t really using Netlify.
(that is what I was going to switch to)