Would be good to have _verifyToken exposed as a public method

[moltar]

Sometimes it is useful to create a JWT and validate it for other than auth purposes. E.g. email verification is another use case I can think of. Sending the token via email (via link) to verify user signup.

[thetutlage]

@moltar I don't think JWT token is a good choice for Email verification. I agree lots of guides claims that JWT token can be used for email verification, but I personally discourage it.

Email tokens should be disposable, means once a token is used, must not be used again and JWT is opposite of that. There is no way to declare a token non-usable, until you store it inside database and blacklist it.

Always the auth tokens should not be used for other purposes.

[moltar]

Email tokens should be disposable, means once a token is used, must not be used again

Why is that?

There is no way to declare a token non-usable, until you store it inside database and blacklist it.

That's an argument for JWT. In which case we probably should not use JWT either :)

[thetutlage]

Why is that?

So you want a user to verify their account 100 times using the same token?

That's an argument for JWT. In which case we probably should not use JWT either :)

Using wrong thing for wrong use case is always end up with this result

[moltar]

But an account can only be verified once. So all other attempts to verify the account would just be ignored. In the same way you'd ignore attempts to verify the account with a specialized token stored in the database.

Also, JWT can be used to auth the user right away as well. Most systems keep user signed in anyways, just pending the email verification. So if user was to click the verify link in the email, the only thing that happens is the account gets flagged as "verified" and everything else goes on as-is.

Also, it's becoming more popular to auth by email. Kinda what Slack does, when you don't remember your password, or don't feel like typing.

[thetutlage]

So you started by saying that you want to use JWT token to verify someone's email, and now you are talking about password less authentication.

Nothing stops you from authenticating a user without a password. As per the API, each request will be validated successfully, until it contains the token in the Auth header.

Now getting that token also doesn't impose that user must have a password.

const user = await User.findBy('email', email)

await auth.generate(user)

See no password is required.

I cannot make changes to the API, until there is a concrete use case.

[moltar]

So you started by saying that you want to use JWT token to verify someone's email, and now you are talking about password less authentication.

I am still saying that I want to verify email with JWT. Passwordless auth was an additional argument.

I am still failing to see how using JWT to verify an email is a bad decision. Your argument that it cannot be revoked. I don't see why it should be. One can mark the user in the database as "deleted" or whatever business logic one has in regards to that. Then those users will not be able to verify or auth or do anything in the system.

This is no different than making a call to the database to check if a specialized generated token is valid. And then STILL having to check other business logic to see if user can be verified or not.

[thetutlage]

The entire point of using the auth interface to generate/verify email verification tokens is invalid.

Why auth should care about giving you tokens for random use cases. You can directly use the JWT package and generate it for any use case.

https://www.npmjs.com/package/jsonwebtoken