Okay sure, if you’re talking about using it without authentication, then all bets are off anyway. IP-based access isn’t secure if you have a malicious/misconfigured device in the same network (and don’t lock your network down specifically to prevent this).
As far as I can tell (i.e. partially infer from behavior since I can’t find detailed documentation), idmap does two things:
Map between local uids/gids and NFS user/group names (NFS v4 users/groups are strings, not integers), both for display purposes on the client (exactly for the ID mismatch problem) and access control on the server (since FS permissions use local IDs)
Map between krb5 principal and NFS user names, for access control on the server
Also, idmap falls back to nobody/nogroup if it can’t map (which is configurable).
For example, my network uses the krb5 realm HOME.DBLSAIKO.NET. My user saiko has three parts, the local user saiko (with uid 1000 on NFS server and my desktop, but not the MacBook), the principal [email protected] and the nfs user string [email protected] which is automatically inferred from the two other names.
In a directory listing, the nfs server reads the directory, idmap converts the stored uid 1000 to [email protected] and sends that to the client, the client converts that back to uid 1000 to display in an ls listing or whatever.
When the client tries to access a file, the security ticket it sends with the request is for [email protected], which the server maps to uid 1000 and checks the permissions on the file system. So for security, the only thing that matters is that idmap correctly works on the server but is independent of client uids.
As a result, the displayed permissions and the actually enforced permissions are independent from one another since they map to two different things. That’s why on my MacBook, even though my user has id 501 and for some reason idmap doesn’t work so it shows my directory on the NFS share being owned by “1000 _lpoperator” instead of “saiko users”, I can still access it because I have the correct security ticket. (And conversely, if I get a security ticket for a different principal while logged in as saiko with working clientside idmap, the nfs share looks like I could access it according to displayed permissions but I get a permission denied error.)
Note that idmap can also work without authentication, but has to be explicitly enabled on the nfs/nfsd kernel module or in /sys. I assume then, instead of the security ticket, the client sends the nfs username with each request and that’s what it checks against.