Web Applications – Authentication and Authorization: Front-End vs Back-End

authenticationauthorizationbackendfront-endweb-applications

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

Best Answer

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.

Related Solutions

REST API – Prevent Abuse to REST API Endpoint

For the first question, your approach seems correct to me. You consume a token in the sendsms entry that can only be generated by the login endpoint. You could also use a generic token created by login, and not easily guessable (it would be equivalent to a cryptographically generated session ID), used as primary key to a database tuple. There you can store whatever you want (for example the number of SMS still allowed to be sent).

You can also store the "state" in a variable and protect it using, say, HMAC, continuously exchanging it between the server and the client, but you still require some server state to defend against replay attacks on non-idempotent endpoints; at minimum, you need a per-session incremental counter.

The second problem is trickier, and you need first to ask yourself what the difference in behaviour (as seen by the server) would be between the app with its logic, and a malicious user sending repeated requests. You might enforce a minimum delay between requests that is comparable to the maximum rate at which the app can be driven, so that there's no longer an advantage in using tricks rather than going through the app.

How to efficiently pass permissions that control view and access of specific front-end elements from backend to the SPA using JWT

Imho you should opt for the more secure approach 1 - option A (see why) and reduce the permission count by creating groups and leverage the possibility of flags.

The client could have:

const accessMode = Object.freeze({
  none: 0,
  execute: 1,
  write: 2,
  read: 4
});

And combine permissions:

file.accessMode = accessMode.read | accessMode.write;

The server would issue:

Claims.FileAccess: 6

Or for TypeScript see FileAccess example here: https://www.typescriptlang.org/docs/handbook/enums.html#computed-and-constant-members