Build and Secure a CRUD Application with Laravel 6

Blog Discussions
, ,
71

This is a fantastic tutorial @holly

I know this is a bit older now, but all the fundamentals still apply.

I have a philosophical question around “authorisation” compared to “authentication” in the context of this article. With a JWT (or OAuth in general I guess) where does the correct abstraction sit when it comes to authorisation?

For example, we may add a scope/permission such as reservations:index and reservations:show, and via RBAC within Auth0’s concept of an “API”, attach those control mechanisms to an access token. The access token JWT is now stateless and self-verifiable, and includes those permissions.

When a request for a resource (a reservation in this case) is made we can validate the token that they can either “index” or “show”. However, when more fine grained control is needed, like a particular reservation, such as in your tutorial, we can no longer rely on the access token. It wouldn’t be practical (or within token size limits) to stuff the claim full with reservation:show:1, reservation:show:2, etc

So… what are my actual questions?

  1. With auth0 authorisation, when is RBAC appropriate? And when to defer to the resource server (in this case the Laravel api)?

  2. If some of authorisation needs to be deferred to a resource server, why use RBAC or claims at all?