At a high level, your app redirects the user to authenticate with the ThaID app, the user approves, and you receive a verified identity assertion. Treat that assertion as a one-time proof of identity, not a standing credential — the moment of verification and your application session are two different things, and conflating them is the first mistake teams make.
The unhappy paths cause most support tickets: the user cancels mid-flow, the app times out, or the same person verifies on a second device. Decide explicitly what each case means for your account model, and never assume the callback will always arrive. Idempotent handling of repeated callbacks saves you from creating duplicate accounts when the network retries.
Once identity is proven, mint your own session with its own lifetime and revocation. Store the minimum identity attributes you actually need rather than the full assertion, both to limit PDPA exposure and to keep your session store lean. Re-verification should be required for high-risk actions, not for every page load.