What is the preferred / common way to separate "access-tokens" in a database design I'm currently having a case where a user has to verify their email, is able to reset his password and can log into a web-interface (so far and not limited to). There a now 3 places where some kind of token is used to give a user access to a specific action.

Web session - Access token used to access API endpoints.
Email verification - Access token used to verify a (new) email-address.
Password reset - Access token used to change a password.

So far I've come up with two possible solutions:
a) A separate table for each token:
There will be a web_session, email_verified and password_reset table.
Pros:

Each table can come with meta-unique properties
You can easily grab data from on of these tables based on their name

Cons:

All tables are kinda related but have very different names (and I couldn't come up with a naming-way to &quot;group&quot; them)
Almost all columns are equal across these tables (id, user_id, token, created_at)
Every time something like this gets added I'd have to create a seperate table with (always / almost?!) the same columns.

b) A unified table with a type / role column:
There's just one table with id, user_id, token, created_at and type (enum) - type can in this case be all sorts of access-type, in our case api-session, email-verification and password-reset. (Of course this could be improved in a way that a token will give general access to a specific thing)
Pros:

It's just one table
Can easily be extended without making it hard to use (I'll always be one table)

Cons:

Another conditional where you'll have to check the type before looking for the token itself
Can get confusing I guess as although it's only one table there are differences based on type

Is there a generally preferred way of doing this (I'm using mariadb if that's important) / is there a third, better way of doing it? Or does it really not matter that much and I'm just overthinking it?
I tried to find existing schemes / db-designs but I couldn't find anything useful as there is afaik no name for this whole thing (please tell me I'm wrong and I just cannot search correctly).
The answer is neither.  Since a user could have multiple tokens, the primary key is not the same and it's meaning within the context of the application is not the same as the tokens used for email verification/password reset.
So:

You have a table for session_token.  If you will search by token to validate a user then the primary key is token.  If you will primarily search by user the primary key will be (user_id,token) with an unique constraint on token.
You have a table for user_token or something similar.  The primary key is (user_id,token_type).  You may or may not need an alternate key on token depending on how things are used.  This is preferable to separate tables as you can add a new type without creating a new table.  You will need a table token_type that provide integrity to that column.  Use values that are easy to understand.

Do not slap an row identifier on each table (id) as:

It does not provide uniqueness
It is unnecessary to replace the existing primary key
It is counterproductive as it will never be used to access either table.