Accessing APIs / Data in Laravel Passport from a Front-end Client

0
votes

I am creating a niche community site+forum where users can sign up, log in, create posts and follow each other.

My tech stack consists of backend APIs in Laravel (using Laravel passport), and a front-end in Vue.js / Nuxt.

I can access all the APIs through Postman, where I call http://localhost:8000/oauth/token to request the token https://laravel.com/docs/master/passport#requesting-password-grant-tokens and then subsequently, I call an API using the provided access_token / bearer token, like http://127.0.0.1:8000/api/v1/tags

My question is, do I NEED a full oauth flow -- my front-end will indefinitely need access to the backend APIs / data in Laravel, but how does the client get access to the data without going through a 2-way handshake with each user session, which seems like overkill? Do I need a Password Grant Token, an Implicit Grant Token, a Personal Access Token, something else? How do I "whitelist" my front-end javascript client while also somewhat protecting my data from bad use? Also, how do I use Passport to authenticate different types of API requests?

Is the Password Grant token appropriate for all of these.... I have 3 broad categories of data available in the APIs:

  1. Type 1: Fully open, no Auth, not tied to a user: Examples:

GET /api/tags - API that gets all tags, this should not require authentication + authorization. This API would be used to display all tags on the /tags page, for example.

  1. Type 2: Admin-only endpoints: Fully closed, not available to anyone, but for me (the Admin). Examples:
POST / PATCH / DELETE /api/tags - APIs that create / update / delete (global) tags, these should only be accessible by me (Admin)
GET /api/users - should only be accessible by me (Admin)
  1. Type 3: User-specific endpoints, Available to a logged-in user only (and of course the Admin). Examples:

POST / PATCH / DELETE /api/user/1/settings - APIs that create / update / delete (user-specific) data, these should only be accessible by a logged-in user, and by me (Admin).

Is the Password Grant token appropriate for all of these?

1
phplaravellaravel-5access-token

1 Answers

0
votes

Implicit grant is usually the best approach for an API driven/SPA.

Since the SPA is a public client, it is unable to securely store information such as a Client Secret. Using the Implicit Flow streamlines authentication by returning tokens without introducing any unnecessary additional steps.

The link to Laravel Passport that you provided to the implicit flow, also goes into detail describing that this type of flow is best used in javascript front apps: https://laravel.com/docs/5.8/passport#implicit-grant-tokens

Hope this helps!