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.