Think about walking into an office building. Before you reach the elevator, someone at the front desk asks who you are, checks your name on a list, and hands you a badge. Only then can you go up.
Every request from a phone or a browser gets the same treatment. Something has to ask "who is this?" before the request gets anywhere near your data.
Many teams build a small service just to be that front desk. It works, but now there's one more service to build, run and keep up to date.
What that layer is really doing
When an API is open to end-user devices, a mobile app, a browser, an IoT sensor, the identity of the caller matters. Authentication has three jobs there:
Check that the call is legitimate
Keep sensitive data away from anyone who shouldn't see it
Tell the rest of the system who is asking, so later steps can act on it
The third one gets forgotten. A purchase request is not just "someone bought something." It's "this customer bought this," and that decides which discount applies and whose payment gets charged.
In a Backend-for-Frontend setup, a middleware layer usually handles all three. The catch is that it becomes its own service with its own deployments, its own bugs, and its own place where every authentication change has to land.
Moving authentication into the execution layer
The other option is to do the check where the API call is already handled. In Unmeshed, each endpoint you expose can be tied to an authentication connection, such as Auth0, Okta or plain API keys, and you can set up more than one. Each endpoint gets its own security level, so a public status call and a payment call don't have to follow the same rule.
Once the caller is verified, their identity goes into the workflow with the request. Nothing sits between the client and the workflow translating who they are.
An e-commerce example shows why that's handy. A customer taps "buy" in a mobile app or a browser. The workflow already knows who they are, so it can apply their personal discount, check inventory and secure the payment, without a separate service having to hand that identity over first.
Before you drop a middleware layer
One thing is worth checking first. If your BFF only does authentication, removing it is simple. If it also reshapes responses or combines data from several services, that work still needs a home. A workflow can take it on, but plan for it instead of assuming it disappears.
A few questions help decide whether the approach fits:
Can each endpoint have its own authentication rule?
Can you use more than one provider at the same time?
Is the caller's identity available to every step in the workflow?
Are credentials stored in one place instead of being copied between services?
The fewer separate services involved in checking who's calling, the fewer places a mistake can hide. If you're maintaining a layer that exists mostly for authentication, Unmeshed is worth a look, because it handles that check in the same place the API call runs.
Top comments (0)