1

In my group we have been asked to implement an authentication-authorization flow in a new web portal that lives in a complex infrastructure.

For historical reason the initial authentication of each user is done by an older "main portal", which does the job for every other service in the infra. This originates a token that is usually carried in the Authorization header (with Bearer prefix). In our case, the absence of this token will drive us to ask the user to authenticate to the "main portal".

But: our new portal will feature several sub-services that require a finer-grained authorization mechanism. We'd like to end up producing (after a successful authentication at the main portal) a second token, meaningless to the rest of the infra, which shall be checked by us for every request thereafter.

Questions are:

  • is this absolutely unusual or somehow wrong/flawed?
  • in which header could we store the second token? (I was thinking at X-Auth-Token)
  • is there any compelling reason/justification for advocating to keep always just one token and swap the initial token with ours in the Authorization/Bearer header?

In case it may be relevant for the answers, we are about to use Spring Security and JWT for the job.

1 Answer 1

1
  • That is not wrong, but redundant. As you say, if there is a legacy system involved, then such an approach might be unavoidable. Effectively what you have an initial authentication, which is later superseded by authentication from sub-service.
  • Yes, X-Auth-Token is an appropriate header for your secondary token.
  • The only point to consider in this case - what happens when you need to close the session? You are introducing a complication that both tokens need to be invalidated to avoid ambiguity.
1
  • 2
    JWTs usually aren't invalidated, but are instead deleted from the client and allowed to expire (requires a short lifetime). Assuming the JWTs are both short-lived-enough and there's no long-lived tokens (refresh tokens, etc.) then simply deleting both of them is the standard practice, although it's good to have some way to invalidate a session if needed. It's not clear what the OP is doing for JWT refresh, though.
    – CBHacking
    Commented Dec 5, 2019 at 1:30

You must log in to answer this question.

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