SMB vs NFS authentication

You basically have it.

User vs Machine vs Share Authentication

SMB/CIFS bases access on user credentials of some sort (whether they be KRB tokens, user/password pairs, or what have you) per session where each session is mapped to one user. NFSv3 uses host-based authentication where all users of a given remote machine share the same connection. SMB/CIFS, specifically the Samba implementation, also allows host-based allow/deny, if you need the feature; window file server probably does as well and if not in the file server subsystem, the firewall will handle it.

SMB/CIFS also implements share-based authentication where the share has its own password.

NFSv4 can be configured to use per-user authentication via kerberos.

Trust Model

NFSv3 relies strongly on the remote machine to enforce permissions by hoping the remote sends truthful, cross-machine-coherent numeric IDs in requests whereas SMB/CIFS enforces permissions on the local disk based on the connection(session)-authenticated remote user.

As a consequence in NFSv3, if a user has root on the remote box, they generally (i.e. by default) have read-only root access to the entire NFSv3 share and can impersonate any other user ID. For a share to a single-user machine, NFS has all_squash as a workaround, but this is per-IP.

On the flip side, most unix-like smb.mount implementations (linux pre-3.3, freebsd, solaris) do not support system-wide multi-session (multiuser) mounts, thus when mounting a remote SMB filesystem, your system's session is as only the user set on mounting, viz. all users act with the permissions of the username set at mount-time. Linux 3.3 and later have cifscreds to mitigate, and there are FUSE SMB/CIFS implementations available. As expected, this was never a problem with Windows clients.

ID Mapping

Also in NFSv3, your numeric UIDs must map exactly: user 1001 on the client machine will be given permissions as user 1001 on the server; there is no textual username mapping. Since SMB/CIFS binds the ID to the session, the mapping is automatic; your share UID matches your credentials.

NFSv4 has a daemon for ID mapping GSS-domain authenticated users, but if you don't already have a GSS-domain deployed, it's likely easier to synchronize your UIDs.

ACLs

NFSv3 and earlier can be a bit sketchy with ACL support (and xattrs are right out). NFS's "POSIX ACLs" are implemented in a sideband RPC (not in the main protocol) so there are a few more things that can go wrong and not all OSes support NFS's POSIX ACLs.

SMB/CIFS generally has no trouble with ACLs. If you need to modify them, windows and unix-like clients can modify Samba shares with their standard mechanisms (GUI and setfacl respectively). I am not sure if unix-like clients can modify ACL-like permissions on a Windows file server share.

NFSv4 has ACLs built in.

SMB and NFS are both merely merely transport protocols for moving data across a network connection. The protocols do not thesmelves provide any kind of authentication. It's up to the server hosting the share to provide authentication and to allow/disallow connection requests.