The fact that you're using JNA to interact with the Windows API isn't really relevant here. Ultimately you're just using the LogonUserW function.
The return value from that, phToken
, is a pointer to a HANDLE
. This handle is just a 64-bit value which represents the actual user logon token, but you're only working with a process-local copy of it. You also don't directly interact with the token, but only use a set of API methods using that handle (or a pointer to it) to manipulate it.
The API specifies that you should close the handle when you're done with it, otherwise you'd leak resources. And once it's closed, that 64-bit value has no meaning. If you request another handle, it very well may be a different 64-bit number.
Once the current process ends, the handle would be automatically closed anyway.
So ultimately, if you want to store that 64-bit number in a database somewhere, you're welcome to do so. It would only be usable by the same process that created it, as long as that handle wasn't closed, in which case there is likely no need for external storage.
If you do have such a use case, you would simply recreate the HANDLE
(the token representation) which you could use to instantiate a HANDLEByReference
if needed. You can create the handle from a Pointer
which you can set the peer value to the 64-bit number you retrieved earlier.