1

I'm working on centralized authentication and authorization API system and got stuck in front-end vs back-end dilemma.

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.

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.

Which one approach is correct? Personally I think more logical is the first proposal, but I can't find any good example which will avoid back-end person telling "but you can add second call to the API for authorization".

  • 2
    What is wrong with 1 call? What value are you getting from 2 calls? These are the questions you need to discuss with the back-end guy. He may have a reason. – NoChance Sep 23 at 1:25
  • @NoChance. I don't see any problem to have it done in 1 call. Back-end guy is telling that authorization part should be accessed with a call which will have a JWT token. Front-end guy states then why not to pass it to some class in the back-end to authorize as JWT was created there anyway. Authentication and authorization API is the same code. – JackTheKnife Sep 23 at 1:49
  • 1
    It would make sense to make to calls if the two services were on different endpoints. But if it's the same, it makes sense to make just one call and return once. – Adriano Sep 23 at 4:16
3

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.

  • I don't think it's right that "the API is under the purview of the BE devs". It's literally the interface between FE and BE, and so is shared purview of both. – bdsl Sep 23 at 9:20
  • @bdsl: 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. – Flater Sep 23 at 9:23
0

As mentioned by @Adriano in the comment, it makes sense when the two services were on different endpoints, and you'll of course find a lot of such designs. But for only one request, I think it's based on your business.

let's say two functions are required in one or two calls,

  1. know who the user is
  2. know what can the user do

If you have scenarios in which only the 1st or the 2nd function is required, then it's reasonable to separate them apart.

If you have clear plan that in near future authentication and authorization will be two services, then just separate them apart.

Otherwise, I think you need to align with backend developer to make sure why - from business context - is two calls required.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.