There are a few other key things to consider. I'd particularly suggest making use of something like PKCE (an extension of OAuth) to reduce the risk of the wron

There are a few other key things to consider. I'd particularly suggest making use of something like PKCE (an extension of OAuth) to reduce the risk of the wrong application intercepting the token - this is important for native mobile apps. Again for native mobile apps - prefer the use of proper Universal Links (iOS) and App Links (Android) - rather than URL schemes. The former is significantly more secure and reduces the probability of MITMing. (See https://magic.cuvva.com/.well-known/apple-app-site-association https://magic.cuvva.com/.well-known/apple-app-site-associati... and https://magic.cuvva.com/.well-known/assetlinks.json https://magic.cuvva.com/.well-known/assetlinks.json as examples of how this works) It's also rather beneficial for the "from" email to be unpredictable. For example, my company includes a nonce - auth+1234blah@cuvva.com. This is to ensure resistance against this attack: https://medium.com/intigriti/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c https://medium.com/intigriti/how-i-hacked-hundreds-of-compan... Obviously they must be one-time-use. Your clients should make use of a "state" parameter (along the lines of the OAuth definition) to ignore any unexpected callbacks. If you detect an attempt to use them again, you should revoke all sessions which stem from the token. Recommend reading all the other OAuth security considerations/caveats also. I find this to be quite a useful reference of things to think about. Wouldn't necessarily recommend actually building a full OAuth server though - tends to be a recipe for making mistakes.