The authoritative server model is a set of rules and polices that reduce the ability of cheaters to adversely affect the game simulation.
The first and foremost principle is that all essential state resides on the game server, and that game clients that connet to the game server treat the server as an authority on state. Less technically stated: everything important lives on the game server, and the game client has very little control over anything.
The biggest area of concern in an authoritative server design is data sent from the client to the server. The client should have as little power over the server as possible.
Movement
Attack
Now I think it is easy enough to see how a hacker would take advantage of the authoritative client examples above. They could simply tamper with the netcode and move anywhere or kill anything.
Where things might be ambigious is in the notion of server validation. Couldn't we still send [x,y] from the client, so long as we validated on the server that the client can actually move to [x,y]? And then who is really the authority...? There's two answers worth exploring.
The first thing to consider is that some features exist along a continuum. Some things end up more client-authoritative and some things are more server-authoritative. Also some pieces of state are safer than others with regards to trust. For example games typically trust information such as the direction in which a player is facing. But then they'll use this heading to calculate the result of an attack on the serverside instead of just letting the client report their own damage. So the authority can be a bit of compromise, but generally with the goal of reducing the client's power.
To figure out where a feature needs to sit along the continuum just ask yourself: what is the worst thing a hacker could do if they modified the data?
The second thing to consider is what it would actually entail to validate whether a player could move to [x,y] or deal 100 damage to entity#56. How would you come to that conclusion? If the answer is just make sure that [x,y] is relatively near their past position, then we end up with hackers that simply move at whatever the maximum speed is that our validator allows. It probably also behaves erratically in different network conditions. By the time we've got this tuned to something that works perfectly (if that is even possible) we'd essentially have reinvented the authoritative server model and may as well have done it that way to start. Especially with something like nengi around.