The backend person might have omitted their valid justifications
Back-end person claims that front-end should to have two calls. First to authenticate user (login process) with JWT response only then second to authorize to retrieve user permissions, role(s) and user data.
At face value, there's little reason to split a single workload into two network calls. The overhead cost of the second call is simply adding to the time to resolve the workload.
However, I suspect that your backend developer may have a valid point but hasn't quite expressed it.
While it makes sense for a login action to also return the authorization information; it can be equally useful to have a authorization-only call, i.e. fetching the user role(s) and user data without needing to log in. It's always possible that some of the data gets corrupted client-side (e.g. the role/permission data), and you'd prefer to silently re-fetch the authorization data as opposed to forcing the user to log in again even though their JWT is still valid.
How to approach conflict in general
Which one approach is correct?
Who says there is one objectively correct approach?
I think the key here is that you haven't drilled down to the core of the BE/FE arguments. You know what both parties want, but you haven't actually figured out WHY they want it, and that's the most important piece of information to have.
As your question reveals, you understand what has been communicated, but are unable to actually weigh the pros and cons of either approach. Drilling down into the arguments gives you more info. Whenever someone says "we need to do X", the immediate response should be "Why?".
As a basic example:
BE We need to separate the calls.
You Why?
BE Because the login action is quite expensive and it would bog down any request which is only interested in retrieving the authorization info.
FE We need to merge these calls.
You Why?
FE Because a second call inherently incurs additional processing time, i.e. the overhead cost of the second call.
Now you are much more able to weigh the options. There are clear conflicts here, both related to performance. But at least now you can try and find a way to either resolve both issues, or weigh up the two options and pick the lesser of two evils.
You can give both parties what they want
That being said, there is an easy way to resolve the issues by giving both devs what they want. Simply add three API calls: login, getAuthorizationInfo, and loginAndGetAuthorizationInfo.
It solves every issue: when consumers need to do both things together, they call the combined method to save on overhead costs. When consumers need to do only one thing and not the other, they save on performance by making sure no unnecessary tasks are executed.
The implementation cost is next to nothing (the combined method really just calls the other two methods), and it gives both parties exactly what they want.
Note: Do take care to not blindly take the "why not both?" approach for every conflict that arises, as you're going to end up with a massively duplicated or contrived codebase. In this particular case, if you find that both arguments are valid (and you're not willing to pick either evil, even if lesser), and factoring in the tiny footprint of the "both" approach, it's a reasonable resolution to the BE/FE conflict.
As an aside
Front-end person is telling that should to have only one request to that API to have user authenticated and authorized at the same time with response back containing JWT, user role(s) and user data.
While I agree in this case that it makes sense that a login action also returns the authorization info due to the high likelihood that a consumer would then ask for the authorization info anyway; it irks me that the FE is trying to dictate what the BE should do. I may be biased as a BE dev myself, but the API is under the purview of the BE devs, and they are the ones making the decision here (that being said, taking others' feedback into account is obviously a good thing).
This is an aside, but if you generalize this into BE/FE conflicts of interest where no middle ground can be reached, each party should have the final say over their domain.
Added from comments below
It is a bit of a volatile point. Ideally, I'd leave the API up to the technical analyst to define. But if we're down to purely BE/FE figuring it out for themselves, the needle should err towards BE. They know how the BE is built and what it reasonably can and can't handle.
Like I said, that doesn't mean any feedback from FE should be outright ignored, but FE shouldn't be able to outright override the BE's decision either. Mutual agreement is obviously preferred, but in cases where it can't be attained, the final say should lie with the BE, in my professional opinion.
