8

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".

3
  • 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, 2019 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. Sep 23, 2019 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, 2019 at 4:16

3 Answers 3

8

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.

3
  • 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, 2019 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, 2019 at 9:23
  • many APIs in fact have both features: a /login endpoint which returns all user data to set client initial state, then something like GET /users/me enpoint to rehydrate user info (or 403 response), especially useful when authorization could be revoked or permissions/information could be edited from an admin anytime Jan 21, 2020 at 21:46
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.

0

I can see this question was posted some time ago, but I am going to throw in my 0.02 cents worth.

IMHO the FE is going to create the login form, that would take in the users username/password. In the medical software world that I work in, Security is critical, so I might be biased here, but in any company, no one wants to be blamed if a user gets hacked. So, if I am writing an application for my employer, I don't want us to have the liability of having that username/password.

In this case, the UI can take the username/password and pass it to Auth0 or Okta, or some other service for Authentication. Even better is a login which goes right to Facebook, Google, Github, Auth0, or Okta. This way the user is putting in a username/password in that system, and they can 'authenticate' the user and pass back the JWT to the original UI for your app.

Store the JWT token in a cookie, and yes, pass that token to the back-end for EVERY SINGLE CALL to the back-end API of your company application.

My Java Spring Boot 3 RESTful endpoints get this JWT token, and then confirm that the token is correct, valid, and not expired. This will also return all the information the back-end wants for this user. I know this makes a call to Auth0, or whatever provider you have, but this makes the back-end stateless. The backend will not have to store the state of the user ever.

I know in logins there is also a refresh token also passed back so if the original token expires, then the refresh token can be used to obtain a new token.

My thinking on this comes from the security side, leaving the username/password on the Authorization service, they are the only ones dealing with a username/password. Other companies and other developers may disagree with this, but again, I stated that this was just my opinion.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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