It depends on what the app does and how it does it.
The first step (authenticating) returns a token with your app id, user email address, a unique user id, an expiration time 5m from issuance, and various other info.
Suppose the token is not verified. If the app only uses the email to identify a client, then a malicious/compromised user could pass your app a forged token to access another user's account.
If the app uses email and id, but not the other fields, then a replay attack is possible on a compromised user: the eavesdropper could simply send along an intercepted token to identify as the compromised user. If the timestamp is checked, this gets harder but is still doable.
The other benefit: once you have verified the token, you can also refresh it in the future (1/day max) to silently re-verify the user. If you instead "re-"verify by repeating the initial credential issuance process, the user will be prompted for 2FA verification.
The first step (authenticating) returns a token with your app id, user email address, a unique user id, an expiration time 5m from issuance, and various other info.
Suppose the token is not verified. If the app only uses the email to identify a client, then a malicious/compromised user could pass your app a forged token to access another user's account.
If the app uses email and id, but not the other fields, then a replay attack is possible on a compromised user: the eavesdropper could simply send along an intercepted token to identify as the compromised user. If the timestamp is checked, this gets harder but is still doable.
The other benefit: once you have verified the token, you can also refresh it in the future (1/day max) to silently re-verify the user. If you instead "re-"verify by repeating the initial credential issuance process, the user will be prompted for 2FA verification.