API Seperation for Backend and Frontend

Level 8

You have core Laravel app and...?

Backend: Angular app (SPA) that consumes the API

1 like

Level 1

@NoLAstNamE Sorry, I don´t understand your question... the "core" application is laravel which exposes a REST API

Level 75

So this is going to be a mobile app also. Otherwise why are you concerned with the front end? Or are you referring to the admin of the sites front end?

I'd suggest looking at some videos here and on Youtube on Laravel Passport and Sanctum, to first decide which you are wanting to use. And study the documentation on each.

But sounds like Passport would work if I understand your description.

Level 1

@jlrdw Yes... one "core" application that serves consumeables (operations & data) via a REST API and multiple clients. One client will be used as administration tool (wich for example allows to restrict access to the API to certain IP adresses as additional security layer) and the question is, if two different API´s (one for the "public" clients and one for the "administration" client) would make sense. For example an endpoint "/product/delete" will only be available on the protected API cause.

Using passport or sanctum for authentication and authorization is another question.

Level 75

@mik3e

and the question is, if two different API´s (one for the "public" clients and one for the "administration" client) would make sense.

The mobile app would be just that, a native app that clients install to interact with your api.

As far as desktop, it would probably be a regular web app for customers.

Normally you would have a mobile friendly app for customers or a native mobile app a customer can install. Many customers don't like installing a bunch of extra apps. That's fine for mobile. If you wanted customers to use a desktop front end that you programmed you would have to make it available to them. And from there they login and data is retrieved from the api.

For example a doctor is setup with a lab, and the doctor can login to the lab and get the lab results.

I would probably have a custom front end for admins to do what's needed on the api. Nova might be a good choice, but that's up to you.

And I don't see why one back end wouldn't be fine.

Another question is do you even need an api, Would a web app work.

Remember the basic back end code for a web app and an api is much the same.

Just me, but I look at needing an api more when organizations or companies are needing to retrieve data.

Just quick example:

A humane society is setup with adopt a pet api and can upload their animals and also show their animals in an object (or iframe) from the adopt a pet api.

I would suggest to first make sure it's really an api you need or just a well written web app.

Edit

Just me, but take amazon as an example. If they have a web app for mobile (which I don't know, I haven't checked) for customer shopping, I am not installing it.

Always make sure customers have alternatives. I know other people that do not like installing a bunch of extra apps on their phone.

Level 1

@jlrdw The architecture is not the point to be discussed - the question is about best security pattern for protecting an API with mixed (sensitive/unsensitive) methods.

Level 1

I think I found a solution by creating a sub-group of API resources an limit the operations for the public API with only(). This way it should be possible to restrict write operations to a "private" route that can be restricted to a set of white-labled IP adresses for example. And it will not lead to code duplication:

Route::prefix('v1')->group(function () {
    Route::apiResource('/products', ProductController::class)->only('index', 'show');

    // Private API for BACKED clients with sensitive operations
    // TODO: Add middleware to restrict access by IP address
    Route::prefix('be')->group(function () {
        Route::apiResource('/products', ProductController::class);
    });
});```

Level 75

@mik3e in an api you have to use some sort of authorization no different from a web app, except an api you assign abilities to the token.

So basically (simplified here) token 1247 can or cannot do something.

Whereas in a web app a user with a certain role either can or cannot do something.

In fact the authorization or RBAC in any app can be the hardest and most complex to work out.

1 like

Level 1

@jlrdw Sure, sanctum (or maybe passport) will be used also. But with this setup there is an additional layer of security on top auf authorization/authentication. So if an admin token or user/password is exposed for any reason, the api still is protected (at least at the IP level).

1 like