-1

When the frontend (A) is hitting the backend for /login, The backend ExpressJs (B) responds with a httpOnly cookie by doing:

ctx.res.cookie('auth-token', jwt.sign({ userId: userId }, APP_SECRET, { expiresIn: 100000 }), {
   httpOnly: true,
   maxAge:  100000,
})

The frontend (A) save this cookie (as httpOnly) and forward this cookie to the backend (B) for the next call (example /getMe). The backend (B) has access to this cookie with cookie.parse(ctx.req.headers.cookie) It works well.

Now another backend (expressJs) (C) needs to login to the Backend (B) with an axios request for example. (C) will hit (B) via /login. A httpCookie is in the header of this call. It works well. But (C) cannot save the cookie as httpOnly and then cannot forward to (B) this cookie for the next call.

How (C) can forward the httpOnly cookie to (B) for doing an authenticated call like /getMe?

Alan
  • 9,167
  • 4
  • 52
  • 70
  • Your first two paragraphs describe a situation where both A and B have access to the cookie. Then, your last paragraph asks a question about C (a server) sending the cookie to B. That doesn't make sense. C doesn't have the cookie. A can't send C the cookie because it's httpOnly so the client A can't get direct access to the cookie. B has the cookie (or could store it), but it wouldn't make sense for it to send it to C because that would appear to break any auth security. I think maybe you need to backup several steps and describe the overall problem as you probably need a different approach. – jfriend00 May 25 '21 at 20:55
  • The behavior of C (expressJs) should be the same as A (ReactJs). C must login first. As you said, (A) can send back the cookie to (B) because it is a client/browser. C is not a client.. so I agree how can C do the authentification and forward the cookie? (C) is a 3rd party that need to consume the (B) API and must be authenticated. hope it helps – Alan May 25 '21 at 21:08
  • Well, C can't login as A unless A gives C its auth credentials which I rather doubt you would want to do. See my answer below for discussion of a "token" which A could request from B and give to C and C could use to access B. – jfriend00 May 25 '21 at 21:27

1 Answers1

1

A technique that is sometimes used on the web for third party access is that client A asks server B for a "token" that it can pass to a third party. That token allows the third party access to server B (or a portion of server B) on behalf of A. That token can be set for an expiration or can have only certain privileges. The token needs to be something is unique enough and long enough that it is hard to guess and when server B grants that token, it has to store it.

For example, Github lets me create a token that allows only access to my gists and then I can provide that to a third party app so it can read/write only my Github gists without ever providing the third party my credentials or any sort of generic access to my whole Github account. Further, I can revoke that token at any time via Github (which would be your server B in this example).

So, you could have client A request an access token from server B for some subset of operations. Server B would see that client A is already authenticated properly as client A so it would generate a token and return it in the response payload (not as a cookie). Client A can then take that token and give it to server C to allow server C to then use it to access server B on its behalf.

Obviously, you have to fully trust server C that it won't misuse whatever privileges you have granted via the token and that it will store and protect the token securely and only use it in service of things that client A is requesting to do (not let any other clients use it). Server B should require https for any token access too.

jfriend00
  • 683,504
  • 96
  • 985
  • 979