I am dealing with this problem. I have created a REST API with some resources. Some are app to app based and therefore I expect to get only the Authentication header with my token (client_credentials token). I am using keycloak to validate the tokens.

Now I am introducing other resources are that are client-owned, these resources receive a token but this time is a user token (password token).

Even though I know by definition this token should be validated only by the user token (since is the owner in the theory of the resource) Im afraid that Im missing the validation of the app token.

Ive seen some app that validate multiple tokens to match multiple security parameters and i am wondering what is the best approach.

The current flow is this:

Having 2 applications

  • Website APP
  • Backend APP


  1. Client logins via keycloak on website app.
  2. Keycloak responds with a user token
  3. User performs actions on the website app using user's tokens given by keycloak, frontend validates this token with keycloak
  4. Frontend app requests its own token to keycloak, its a unique token per app
  5. Frontend app calls backend to get non-user specific info, its a rest call using frontend's app token
  6. User perform an action in the frontend that is user's specific (like edit its own user info), frontend requests to the backend using again only the frontend app token.

Having this flow I can notice never validate website app token, except in the scenarios when website app requests information that is not user-related, like requesting list of products, the weather of whatever the backend responds. Should then the frontend gets the user#id front he current session/user token and send it as another parameter to the backend? or should it just forward the user's token? should it request using both tokens in different headers so the backend will validate both?

What is the standard in these cases? Is there any documentation I can find that denies the validation of multiple tokens or recommends to keep validating just one?

Current flow:

enter image description here


1 Answer 1


You should not (and cannot securely) validate the application token with a user request, if the user-request goes directly to the back-end. Think of it this way: if your app has N users, your back-end has N+1 different client identities: one for each user, and one for the webapp. Each client can access different resources, and you must never let one client see another client's token.

If the user's client (web browser) can send the webapp's token directly to the back-end, that means the user knows the webapp's access token and could simply send requests as the webapp itself. You presumably don't want to allow this.

Now, if you want to relay all requests through the webapp server and avoid exposing the back-end to the general Internet at all - which can be a good idea, for the sake of flexibility and also for reducing attack surface - then the webapp could take the user's request and forward it to the back-end, optionally attaching the webapp's own token, without the user ever gaining access to the webapp's token. However, this adds very little security compared to just forwarding the request unmodified, and doing that adds little over just allowing direct interaction between the user and the back-end (assuming you know how to lock down the back-end server properly, such that only the user-facing HTTPS endpoint is exposed).

  • Thanks for the reply, maybe I didnt explain it well so I added a graph. The user logs in through the login from keycloak that returns a token to the web app, the web app never know any credentials of the user nor the user knows any credentials of the app. The app in background gets its own unique application token that is the one that sends to the backend API, My question now is... when the web app is accessing user-owned resources on the backend api, should it send both tokens? its own token and foward the user's token?
    – jpganz18
    Jul 27, 2020 at 8:26
  • The diagram helps, thanks. No real need to include the web app token; you can if you want, but you should have secured the back-end such that only the web app could reach it anyhow, and that - combined with the user token that is, after all, the only thing logically necessary for accessing user data - is sufficient. It also still risks exposing the web app token to the user, if there's some error or something that echoes the web app's request headers back to the user, though that's very unlikely. Anyhow, as my last paragraph says of adding the webapp token: "this adds very little security".
    – CBHacking
    Jul 28, 2020 at 6:25

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .