Can anyone briefly describe me what is the biggest difference between SMB authentication and NFS v.3 authentication?
I think that in SMB it is based on user's login and password whereas in NFS it is based on host 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.
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.
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.
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.