I am using JSON web tokens, but this authentication token can be any token from which a unique user can be derived.
I am designing a REST API that allows CRUD operations on resources owned by specific users in our domain. This ownership is determined by a user ID field for each document. Users know their own ID (and thus can send them through their client), and can get their authentication token through single sign-on.
This token is not generated on our servers, it is instead generated on a third-party server (Firebase), and then obtained by both the client and server. The server would then check if the token obtained and then sent by the client is the same as the one expected.
There are two approaches to authenticating here:
- Have the client pass the user ID and respective authentication token.
- Have the client only pass the authentication token, and derive the user ID from this token server-side.
In my own system the user ID would be passed within the URL itself, and a HTTP header would be used for the token. But the above two approaches can be generalized to any method of passing this information.
The benefits of (1) are the greater granularity for errors. If the authentication token is invalid, the server will be able to log which user the client expected the token to authenticate for. (1) also allows authentication tokens (such as administrative ones) to authenticate for multiple users, while still telling the server to perform CRUD operations for one specific user.
However, (2) seems to have a much simpler interface for the client. This is because in the majority of cases when the token is valid, passing the user ID is duplicated information since it can be derived anyway.
Are there any other factors to consider here?