Token-based authentication: Application vs Server

Question

Just found out that the basic workflow for token-based authentication is as follows:

1. User requests access by providing username and password
2. The application validates the credentials and returns a token to the client
3. The token is then stored on the client and sent with every request henceforth
4. The server then validates the token and returns private data as a response

Now, I understand the flow more or less, however, I'm having issues with the terms application, client and server. I understand the term server to mean where the API is stored... which is also part of the application. But the application could also be anything from a web app to a mobile app on various platforms... a client in other words.

So isn't it true that the application includes both the server and the client. So what does it mean by each term exactly, in the above context?

On second thoughts... I guess the original token is being generated on the server side, and this is then being returned to the client. Is this true?

Answer 1

Those terms terms are pretty overloaded in software development, so it's always difficult to nail down the exact meaning without focusing in a very specific context. Bear in mind that even authentication can be seen as a very broad context.

I would rephrase your proposed workflow to the following:

1. User requests access by providing a set of user credentials _{(we don't have to use passwords all the time, see passwordless authentication out of curiosity).}
2. The authorization server validates the user identity and, if valid, issues an access token.
3. The client application from which the user started the process receives and stores the issued access token.
4. The client application calls into a resource server using the access token in order to obtain user associated resources.

Damn, now we have even more terms, but let's try to fix that by providing some definitions.

First, the ones more generic:

Client: An application that obtains information from a server for local use.

Credentials: Usernames, passwords, email addresses—any of a variety of means for communicating parties to generate or obtain security tokens.

(source: Auth0 Identity Glossary)

Then definitions within the context of OAuth 2.0 and/or OpenID Connect:

Authorization server: The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Resource server: The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens.

Client: An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

(source: RFC 6749)

It's not even useful trying to define application, but what we should conclude from the other definitions is the following:

• As you said, a client can range from web, to mobile to event server-side applications.
• The role of the authorization server and resource server can be played by the same component, for example, a Web API that has an endpoint protected by HTTP basic authentication that can be used to exchange a pair of username/password credentials with an access token and then all the remaining API endpoints are protected in such way that only allow access if you provide that access token.

Finally, one final note to clarify your last question, yes, the creation of the access tokens need to happen on the server side because the creation of the token will be accompanied by some kind of mechanism that will ensure that the token cannot be tampered with and was in fact created by a very well-know entity. For the case of JWT's this mechanism consists of signing the token which is accomplished by having the server know a secret that no one else knows.