Under NFSv4, direct uid/gid is no longer used, but the RPC.idmapd process determines privilege. I'm not really sure how it works beyond continuing to work when uid/gid synchronization is in place for NFSv3 and the connection is upgraded.
There is also an NFS ACL standard, but I don't know anything about it.
looooool
(Seriously, though, could someone tell me why this was supposed to make sense?)
I've worked somewhere with a lot of NFS, and they had centralized account management, so everything was fine other than actual security, at least until we hit the limit of 16-bit uids. That place had a different centralized account management for production, so uids weren't consistent between corp and prod, but NFS in prod was very limited. (And you wouldn't nfs between corp and prod either)
I worked somewhere else without real centralized management of accounts on prod, and it was a PITA to bring that back under control, when it started becoming important. Even without intentional use of uids, it's convenient that they all line up on all servers; and it's a pain to change a uid that already exists on the system.
Like much of Unix, it was worse-is-better, and pretty productive for a site. (Well, until there was a problem reaching the NFS server, or until there was a problem with an application license manager that everyone needed.)
The TrueNAS people (ixsystems) have a patch to bring it to Linux and ZFS; though from what I've heard upstream LKML lists aren't too enthused since they'd rather see this being used by an in-kernel filesystem.
Technically the server doesn't need to have a UID/GID database that's aligned with the client, what's required is that all clients of the same server are aligned. The server will take the numerical UID/GIDs from the RPC sent by the client and perform Posix style permission checks using the owner UID, owner GID, and mode bits stored in the inode of the file or directory. The server doesn't need to known what user the UID corresponds to.
This was maintained using YP/NIS. But Sun was too big for a single YP/NIS domain, so there was a hack where each YP/NIS master was populated via some kind of uber-master database. At least at one point, this consisted of plain text files on a filesystem that was NFS-mounted by every YP/NIS master....
This was all terribly insecure. Since everybody had root on their own workstations, you could `su root` and then `su somebody` to get processes running with their UID, and then you could read and write all their files over NFS. But remember, this was back in the day when we sent passwords around in the clear, we used insecure tools like telnet and ftp and BSD tools like rsh/rcp/rlogin. So NFS was "no more insecure" than anything else running on the network. But that was ok, because everything was behind a firewall. (Some sarcasm in those last bits, in case it wasn't obvious.)
Think about the environment it was originally used in — large organizations, computers which cost as much as a car, LANs which aren't easily accessible (e.g. the Unix people have access but laptops are expensive oddity and the sales people are probably sitting in front of a DOS box or shelled into that Unix server), etc. It's more defensible when your unix administrator is going to configure each of the servers to use the same NIS user directory.
All of that broke down when IP networking became the default, every desk in the building had a network port, and things like WiFi and laptops completely blew away the idea that the clients were managed by a single administrative group.
Note that I'm not arguing that Sun was a leader in security, but they did make some efforts that other companies didn't.