Block authentication until user is verified?

eric

Is there a workflow within fusion auth, to not authenticate a self registered user until their registration is verified by email?

My current workaround is to locally track which users have been verified in our own database. Then using webhooks listen for the user.registration.verify event to update our own DB and allow access.

Did I miss anywhere in the FusionAuth docs that would enable this workflow to avoid the mentioned workaround?

dan

Are you using oauth or the login api for your authentication?

If the latter, you could just check for registration email verification after authentication and disallow access if it wasn't true.

If the former, I don't believe there's a way to do this directly (no settings to enable this behavior).

There are some workarounds. You suggested the webhook. You could also, depending on your system, put the information about the email verification into the JWT using a lambda and have APIs consuming that JWT check.

I'd suggest opening a github issue with more details about what you would like to accomplish.

eric

Great suggestion about using the JWT!

I am indeed using oauth for authentication. Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?

with the former just saving me the effort of getting the user profile in my api?

Thanks for the speedy response!

dan

Is modifying the JWT via a lambda equivalent to accessing the verified property of the user profile?

Within a lambda, you have access to the user and registration properties. So you'd pull the verified property from wherever you wanted and put it into the JWT as a custom claim. Here's a blog post about how that might work.

So yes, it is the same data. It's the tradeoff between a bigger JWT and having to make the additional call from your API.

Don't forget that the JWT will live for a while, so if this sequence happens and you use the JWT, you might have a user with a verified email prevented from using the API.

user registers
JWT issued, with verified set to false because the user isn't verified.
User verifies their email
User visits API, but is denied because the JWT has stale data.

I don't know timelines and how long your JWTs live for, but this is something to consider. Does that answer your question?

eric

@dan yes this answers my question perfectly! I appreciate the detailed answer.