Build and Secure a CRUD Application with Laravel 6

Blog Discussions
, ,
63

Thanks for the support, I’m grateful

2 Likes
64

We’re here for you @jackieriel!

1 Like
65

@holly First off, apologies for my very late reply! I’ve got no other excuse than “life happens”. In any case, thank you for your clarifications. I’m starting to understand how the registration/authentication process works.

After much deliberation, we decided to give the Universal Login a go and try integrating it with our Laravel app. But then, there are a couple more things that we’d need clarified, before I proceed any further.

First and foremost, how could one set up Laravel, so that it will persist the user’s extra attributes, as user_metadata, into Auth0’s database? In other words, what’s required so that Laravel is allowed to forward the user’s metadata to Auth0, as soon as the user updates it?

And second, how could that piece of information be retrieved back into Laravel, so that it can be used in .blade views, when needed?

My initial idea was to simply persist any extra info (which I’d mark as optional) of the user in Laravel’s database, along with the user’s mandatory fields, and just retrieve any of those meta fields simply based on user’s sub unique identifier. What do you think, would that be an easier and/or better approach? But then, what about the user-inaccessible metadata, such as the subscription tier, which should ideally go into app_metadata, as per your explanation?

Many thanks!

66

i can’t with composer laravel/ui. but i can make it with composer laravel/ui “^1.2”

67

Thank you @htooak2014! I’m going to run through this today and see if there are any other dependency incompatibilities with the tutorial.

1 Like
68

Perfect! Let us know Holy once you have any update!

69

This topic was automatically closed after 3 days. New replies are no longer allowed.

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?

72

@robertino.calcaterra would you be able to get help on that front from your team? Thanks!

74

Do you know if this was ever answered Konrad? Perhaps in a different thread?

75

Hey @chris-workinggears,
Sorry for the late reply and thank you for your patience :pray:

To answer your questions, I think we need to clarify that the resource server is always responsible for checking authorization. The resource server makes authorization decisions based on information that may come from different sources: the access token, a database, a remote service, etc.

That said, let me try to answer your questions.

Question 1.
Permission-based or RBAC-based authorization is appropriate when you have a well-defined set of permissions that don’t change dynamically. Pure RBAC is not appropriate for your example about using scopes such as reservation:show:1, reservation:show:2, etc., because, in this case, resources are dynamically generated. You also mentioned practical issues with the token size, which is a legitimate concern.
Bearing in mind that the resource server is responsible for making authorization decisions, it can combine information coming from the access token with information coming from other sources to allow or deny access to a resource.
For example, if the user can see only their own reservations, the resource server will evaluate the following information to make its decision:

  • the presence of the reservation:show scope in the access token
  • the user id associated with the access token (sub claim)
  • the reservation id coming as a parameter in the HTTP request
  • the user id and reservation id stored in the reservation database

Combining the information coming from these different sources, it can make its authorization decision and allow or deny the user access to that specific resource.

Question 2.
As said before, actually authorization decisions always happen on the resource server side.
The point here is: how convenient is it to have part of this information (i.e. scopes) coming from the access token?
As usual, it’s a matter of evaluation based on the specific context.
In simple cases, RBAC is enough. In slightly more complex cases, you may need to integrate information coming from the access token with information coming from other sources.
In even more complex cases, it’s preferable using different approaches like ABAC or FGA.

I hope I answered your questions.

1 Like
76

Perfect, thanks for the great answer Andrea.
That answers all the questions I had - cheers

1 Like
77

Glad to have been helpful! :slightly_smiling_face: