I know that laravel-passport use JWT but it checks database per access-token request to check that this token is revoked or not. this break the meaning of JWT which is self-signing without database check. also, this made my RESTfull API stateful and my JWT is a sessionId and not truly an access token.
This checking made my authentication requests slower and is a bottleneck when my API is under pressure.
now I want to know is there any solution to disable revoke checking in laravel-passport? or a better solution such as storing data in cacheDB such as Redis? and if there is no solution in laravel-passport is there any other package to solve my problem?
Related
I use firebase authentication in my laravel project and I am curious if there is such a way to give users roles/permissions.
Normally I use laravel authorization to get over it but now my user data are on the firebase.
Firebase Authentication (as its name implies) only handles authentication: verifying the user's identity. It intentionally does not provide any form of authorization: determining what the user's access permissions are.
Many of Firebase's other products have their own authorization mechanism that builds on top of Authentication, such as the server-side security rules of the Realtime Database, Cloud Firestore, and Cloud Storage.
You will need to do something similar in your own server-side code to implement authorization for your app. You'll typically follow this recipe:
Pass the ID token of the user from the client to your server-side code.
Decode and verify the ID token to securely determine who the user is.
Look up the authorization of the user, either in a data store of your own, and/or from the custom claims from their token.
Enforce that the user only accesses the data they're authorized for.
This is pretty much the same process that Firebase's own services also follow.
I'm currently using Laravel 5.6 with the Laravel JWT library for a new web app.
I would like to store the JWT in a cookie without using a conventional session but there doesn't seem to be an easy way of going about this with the JWT library.
In my Auth controller I return the token in a cookie, but Laravel still starts a session which I don't want since I want the session inferred from the cookie.
I also went into Kernel.php and removed some of the Session stuff from the web middleware group but then that caused a runtime exception saying "Session store not set on request."
I've seen some hacked together solutions that were half implemented, but I would like hear some insight from anyone that has done this elegantly or felt like their solution was correct.
Thanks
For my purpose I determined that using encrypted cookies will suffice for the web application (using Redis as a cache), and then using JWTs for the mobile API.
I am developing mobile application back-end service using laravel 5.3. I am following REST API. Application having payment gateway integration and it needs more security.
I followed jwt auth by using the tymon/jwt-auth library for laravel.
I have few concern, my token getting expired after 1 hour, after that server returning token expired error and how application developer can handle this situation? Asking user to log in, again and again, is not possible.
How can app developer handle it?
What is the best and more secure approach?
in config/jwt.php change 'ttl' => 60 to whatever number you need, the numbers represent the minutes a token can live, but the best approach is to use the RefreshToken, since your app will be more secure from unwanted users.
Since the last version (5.2), cookies are disabled in Lumen. I'm currently making an API in Lumen with JWT authentication.
To secure my application from CSRF attacks I need to set a csrf cookie. But what is the best way to handle that now?
VerifyCsrfToken Middleware was removed in this commit.
From Lumen 5.2 documentation:
Lumen 5.2 represents a more decided shift towards focusing on stateless APIs.
So, if you need Csrf Token verification, you have to implement it storing it in a meta tag or inside a JWT payload as a private claim (you will need to implement the new claim, i.e.: here).
If it was removed, there's probably a good reason. Here I let some links that maybe can help you move on.
CSRF Token necessary when using Stateless(= Sessionless) Authentication?
Where to store JWT in browser? How to protect against CSRF?
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage#post-2748616172
I'm planing to create a few simple REST web services to be used by some other applications (everything internal, not facing Internet). For certain reasons the applications should work with SSO (Windows, NTLM or other). The issue I have is how to do the authentication in the web service.
The application calling the web service has no knowledge of the users password so I'm kind of lost on how to authenticate against REST without having the user to login? eg. avoid Basic Authentication
I would like to avoid login due to simplicity for the user and not having to handle passwords in my applications. What are my options? Am I missing something obvious?
Would this be a solution:
create token, pass it to service and store it in database. web service checks if token exists in database. (expiration handling?)
The most common solution to this problem is, as you mentioned, a simple key or token based authentication. This is how a lot of google services (e.g maps) work. You simply generate a key on your service provider for each consumer, store it in your database, and validate that all calls pass a valid key.
More sophisticated options would be HMAC or OAuth authentication. Given your situation, i.e. providing services only within your intranet, I'd say keep it simple and go with a single key authentication.
In the above scenario I don't see the need for handling expiration. Nonetheless, if you'd like to implement it, then you could
on each client request, generate a timestamp based token on the server
in your reply to the request, also include this token
client should use both the static API key and the dynamic token in subsequent requests
server should check the token's lifetime and accept / refuse the request as necessary.