16

I am currently looking into authentication protocols which work well with REST API, in java. There is something fundamental I don't understand: I read a lot of material about OAuth protocol, SSL, basic HTTP auth, digest etc.. And in all of them there are apparently different meanings of the term "client". In most, from my understanding, this term means web application, or the browser. But in some, for instance basic HTTP authentication, this term refers to the user himself.

I don't understand exactly how can an instance of a web application can be, or needs to be, authenticated. I know there are certificates involved in the process, but as I see it, they just take care of securely transferring the message to the server, and prevent replay and MITM attacks. In OAuth, there needs to be a token in the cert, after a username+password exchange, but since the username and password belong the user himself, as I understand it, where is the part that authenticates the client?

There are some protocols that use private and public keys in the server side as well as in the client side, which actually makes sure the client is "who it says it is". But do these keys have to be applied to every instance of this web app? I'm confused.

In which cases, anyway, will we need client authentication? Isn't it enough to authenticate the user and take care of message integrity?

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
rita potter
  • 163
  • 1
  • 6

2 Answers2

12

The client is a network concept: the data is transported between two machines, the server and the client. The client is the one who initiates the conversation; the server is the one who is sitting all day, waiting for clients to connect.

The user is the biological entity (presumed human) who controls the client. Authentication is about the server making sure that whatever it receives originates from a specific user. However, the server is not talking to the user (the human being) but to the client (the user's computer). When a server authenticates the user by way of a stored HTTP cookie, it is really authenticating the client: since the cookie value was previously sent to a specific client, only that client may show the exact cookie value. The server then assumes that a given client is under exclusive control of its purported human owner, and then feels content that the human user has been involved.

The distinction between client and user becomes apparent when the user's machine is subverted (e.g. infected by malware). The machine will begin to do things outside of the control of the human user.

To make an analogy, if you have a dog and that dog bites me, then I will sue you, not the dog, because the dog is supposed to be under your control. Even if the dog contracts rabies (explaining its vindicative behaviour), it is still your responsibility. In that sense, authenticating the dog is as good as authenticating you (in the eyes of my lawyers, at least) and it is up to you to make sure that your dog is really under your exclusive control.

With Web applications and "API", the picture can become more complex, because the server can also behave as a client with regards to another server. That secondary server may want to make sure of the identity of either the first server, or the human user who initiated the whole process, or both. The terminology can be source of confusion if the same terms are reused.

When using public/private key pairs, the private key owner (the machine which contains the private key) uses it to perform some computation which links to another computation which involves the public key. For instance, with digital signatures, the private key owner generates a signature over a given message (a sequence of bytes); the signature can be verified by using the public key. Digital signatures are a good tool for authentication: by computing a signature on a challenge sent by a verifier, the private key owner demonstrates to that verifier its mastery of the private key. The verifier thus obtains a guarantee that it is really talking to "whoever controls the private key corresponding to a given public key". The interesting part of the process is that the verifier needs not know the private key for that, so it is possible to verify a signature without having the power to generate signatures.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • Thank you for the detailed answer! So, you're saying that in order to authenticate the user we have to authenticate the client - sort of thing? That part, I think, is starting to get clearer. But the last part, about signatures and key pairs; That part still sounds to me as if refers solely to the client. The client is the one with the private key, so the server is basically verifying the identity of the client, no matter which user is sending the request, no? – rita potter Apr 04 '13 at 14:28
  • A private key is a big mathematical object; there is absolutely no way that a human user will compute signatures in his head. So yes, the user will use a computer, which contains the private key, so the authentication is really about the user's machine. That machine can be "small", e.g. a smart card -- the server on the other side of the Internet makes sure that the smart card was involved; the link from card to human user is supposed to be handled "elsewhere". – Thomas Pornin Apr 04 '13 at 14:31
  • Ok, thanks. Question- there should be only one user per client? If that's the case, then yes it makes sense all of the above. But what if there are several users using the same client? Or am I missing something here? – rita potter Apr 04 '13 at 14:38
  • It really depends on the context. The cornerstone of the whole thing is that a server authenticates a machine (the _client_ which is talking to it), and this relates to the human user exactly insofar as the client machine is under control of the human user. If there are several distinct human users on a single machine, then these users implicitly trust the OS on that machine (and the sysadmin) for not playing mean games on them. Most servers don't care. When you connect to your bank Web site, it is _your_ job to use only a "clean", non-hostile computer. – Thomas Pornin Apr 04 '13 at 15:00
6

In OAuth, there are three parties, the resource owner (the user), the client (the application being authenticated with and the resource server (the server that actually validates the user's credentials). The client is the web application because it want's the resource server to verify (and possibly provide details about) the resource owner (user) that is trying to log in.

It is important to authenticate the client for several modes of OAuth because details about the user and possibly even permissions to use the user's account on the resource server are going to be granted to the web application (client).

The use of the terms is confusing since client often is synonymous with user, but in the case of OAuth, it is just how they choose the terminology.

In other systems, the distinction between client and user can mean if the computer being connected from is verified or the person using it. Some authentication mechanisms are designed to verify hardware rather than users. A computer system for example could have a private certificate shared by multiple users that verifies the client being used is a given computer, but it would provide no details about the user of that computer.

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • thanks! I know there are three parties to this protocol. The exception is two-legged OAuth, and in that case, for instance, what is the point of authenticating the client? In any protocol which works on a client-server scenario, why do we need to authenticate the client (application)? And if indeed they do it, how? – rita potter Apr 04 '13 at 14:06