---
title: "Comment by Steven Mock on \"One Oracle APEX App, Many Ways to Sign In\" | Hashnode"
description: "This is a useful breakdown, especially the part most people skip: every method has to end on the same user row, or you slowly end up with one person holding two"
url: "https://hashnode.com/posts/one-oracle-apex-app-many-ways-to-sign-in/6aee11a96d23945c4e908bd8/comment/6aeeb3630ad05f20581fcb8d"
---

[Discussion](https://hashnode.com/posts/one-oracle-apex-app-many-ways-to-sign-in/6aee11a96d23945c4e908bd8)

Comment [One Oracle APEX App, Many Ways to Sign In](https://hashnode.com/posts/one-oracle-apex-app-many-ways-to-sign-in/6aee11a96d23945c4e908bd8)

[Steven Mock](https://hashnode.com/@stevenmock)

[4d ago](https://hashnode.com/posts/one-oracle-apex-app-many-ways-to-sign-in/6aee11a96d23945c4e908bd8/comment/6aeeb3630ad05f20581fcb8d)

This is a useful breakdown, especially the part most people skip: every method has to end on the same user row, or you slowly end up with one person holding two accounts. Mapping by Google's sub first, then by email, is the right order — I've seen the duplicate-account mess that comes from matching on email alone. The security checklist is the other piece I'd underline. More ways in really does mean more doors to lock, and checking the same rules for every method is what keeps it honest. Do you have a plan for when a member changes their Google email — does the sub still carry them through cleanly?