That is all just external implementation details. Not sure if it was you or someone else, but the main argument in defense of the OP as in it reasonable, was that the name is wrong. That it ought to be idAdmin. None of what you just described should have anything to do with user being or not being an admin. In place of checking “isAdmin” for null, the semantical and resourcewise equivalent would be a third variable for “admin rights having been validated” or whatever. Conflating it in this one variable while renaming it to isAdmin or similar, would be even less sensical.. what if somewhere else in the code you have to check whether the initial validations have been made (while the actual role or whether is admin or not is irrelevant), you’d have to check if isAdmin equals null, which in that context would be confusing, ambiguous (i.e someone reading that bit will not know this is what is being checked without additional documentation) and just a code smell in general. You do want to make the important things unambiguous and self-documenting. Even more so the bigger the codebase is and the more contributors there are across its lifetime and in parallel at any given time.
But if we go with the original meaning of roles overall, then the union type is just a code smell that warrants a proper role thing around it.