Level 80
@yisusvzq A client uses a client ID and secret to request access tokens. An access token is then used to access your API and also identify the user making the request.
Feb 10, 2021
13
Level 1
API and users Auth: best practices with Lumen Passport
Hi everyone,
I'm currently developing a tiny and simple API with Lumen. I need to implement authentication for users, but I would also like to have control of the applications that are requesting my API.
This is the case: I'm having two kind of routes:
- The ones that require the user to be logged in, with a valid Bearer token in the Header of the request. I have this working nicely right now with Lumen Passport.
- The ones that will not require the user to be logged. In fact, I don't need to make any reference to users.
Both kind of routes will be reachable by a Front and a Mobile App. I don't want anyone else to be able to request my API, so I was thinking on some kind of client authorization with Passport.
The thing is that I can't think of a way to combine both auth's. I don't even know how to check that only certain clients are going to be able to reach my endpoints, and others will get a 401.
The first idea that came to my mind was giving them the client_id and client_secret created when running
php artisan passport:install
but I don't know how to check them in a middleware. I'm pretty sure it's quite simple, but I'm stuck.
I'd appreciate any hint. Thanks a lot in advance!!
Level 1
Thanks!
There's a gap where I get lost: a client (let's say a Mobile App) requests the access token. Then, it includes the access token in the Header as Authorization. OK so far?
Then, it requests the user's Bearer token that must be also included in the Header as Authorization, am I right? But the previous token must be kept in the Header as it identifies the client! That what's driving me crazy.
Level 80
@yisusvzq What previous token? There is no “previous” token. A client requests an access token for a user, and then the user uses that token for subsequent API requests.
Level 75
Also @yisusvzq you might want to look at this tutorial:
Level 1
Thanks everybody.
I think I'm not being clear or explaining myself.
What I have currently: a Lumen API with user auth, so that users must send their username and password to get a token which must be included in the Header of every new request. That's done on my API, and working fine.
But with this, I can request my API from anywhere, any client that knows the procedure can authenticate. I can do it on Postman.
What I'm looking for is to allow only certain clients to do so, throughout an API Key or something similar. A way to identify and allow or deny a client to make any request, including the one to get the user's token. In my case, a Front web and a Mobile App. Having in mind that some routes are out of the user's auth middleware, so that a not-logged in user can request but only from authorized clients.
Level 1
Let me add an example:
I have 2 endpoints:
$router->get('/hello', 'DummyController@index'); // without login
$router->get('/resources', 'ResourceController@index'); // with login
The first one can be requested without user to be logged in, I don't need a user's Bearer token to be included in the Header. I have this working fine, right now.
However, I do need so in the second endpoint as only an authenticated user must be able to get the resources.
Although one endpoint needs a user's token and the other one doesn't, I need both to be requested only by certain clients (a web client and a mobile app).
I guess I'll need two middleware: one for checking the client, and another one to check the user's auth (that I already have). The one for the client is which I can't understand. I'll need to include then 2 bearers when requesting the second endpoint? One for the client and another for the user?
Level 80
@yisusvzq A “client” doesn’t send requests. A client has a set of credentials that are used to request tokens on behalf of users. The user then uses the token to identify themselves when making API requests.
At no point do a client make an API request and go, “Hello, API. I’m the mobile client”. A client is only involved when a request is send to your /oauth/token endpoint. A client ID and secret is passed, and then your endpoint goes, “mobile client wants a token for user with username and password” and returns an access token. That’s it.
I think you need to have a read up on OAuth and understand the flow.
Level 1
Perhaps the term "client" was not correct, sorry.
I meant, for example, a Web App or a Mobile App. They do send request to the API, but not all of those requests must include a Bearer token that identifies the user (the person who writes username and password) as some routes are not included within the auth middleware that checks username and password.
Level 80
Yes, but then those clients don’t include anything in the headers to say, “I’m an iOS app” or whatever. That’s just not what OAuth clients are for.
OAuth clients are for issuing access tokens and nothing more. You don’t pass anything in an API request to say, “This request is coming from Client A”.
Again, read up on OAuth and get an understanding of how it works and applicable use cases.
Level 2
So you're looking for more CSRF but for an API, than a API token?
Level 2
Is this what you mean?
Level 1
@gaiustemple Lumen doesn't support Sanctum.
Level 1
Sorry for the late answer. I eventually understood better OAuth in part thanks to oauth.com where I could find and read about the different servers.
Thank you all for you answers.
1 like
Please or to participate in this conversation.