I want to authenticate socket.io clients based on client session data created by Laravel.
What I have thought of is :
A - emitting username and email from client to server;
B - storing the data my socket.io server needs in Redis in php after user logs in and then reading it in Node.js based on session cookie id.
I will probably have to store sessionId -> "email, name" in Redis if I prefer this approach.;
C - using Redis session driver in Laravel, decoding cookies set by Laravel, accessing Laravel session values from Node.js, unserializing and decoding them;
Approach A is obviously very insecure and could be used only to prove concept.
Approach C seems better since I do not have to duplicate or manage session data but only to decode it. This way however couples my application to the implementation details of Laravel managed sessions and thus doesnt seem to be appropriate.
Approach B looks more promising and it is simpler to implement.
However using approach B means I have to manage some session data myself in order for socket.io to be able to read it. Doing so may make Laravel session data and session data I store in Redis mutually inconsistent and this will happen at some point in the time. In some extreme case for example an expired session id could be reused and some socket.io client will be authenticated incorrectly as another user. I cant think of more trivial case at this moment but because of this incosistency I assume its possible that there is such case and both security and UX could be compromised.
What is a more elegant, robust and secure way to achieve user authentication based on Laravel session data in socket.io application? If there are no drastically better approaches and I assume approach B is best what could I do to improve consistency between session data I manage using Redis and Laravel session data.
The whole point as far as I can summarize is actually accessing Laravel session data outside Laravel and php and identifying clients by sessionId, email and username.
I suggest you to use JSON Web Token authentication.
JSON Web Token (JWt) is a relatively new token format used in space-constrained environments such as HTTP Authorization headers. JWT is architected as a method for transferring security claims based between parties. More detailed info about JWT
The easiest way to do this with Laravel is by a using a package like this one. Or you can implement it by yourserlf.
Using JWT auth you will be able to access the user from the token. For example:
$user = JWTAuth::parseToken()->toUser();
For detailed information about how to use 'jwt-auth' take a look here.
As already noted by Alexandros you should use JWT.
Authenticate JWTs with socket.io is a breeze.
You could use socketio-auth and jsonwebtoken as described very well in this article to authenticate your users. Furthermore you could use dotenv to read the secret-key for the signed tokens from the Laravel .env-file.
For me it's working fine, although you have to think of invalidation of the tokens. In Laravel jwt-auth takes care of this by using a blacklist. So in your node server you have to handle this by yourself. Or keep the liftetime short.
I had found a good solution for this about a year ago. I decided to make it a module, its really easy to use. helps you get the cookie without hard coding it. helps you get that session Id and retrieve it from mysql and redis
https://www.npmjs.com/package/node-laravel-session
this way you can share all of your session. you can also utilize the session in order to sign up a user to certain rooms
Related
This is a question about the best way of implementing JWT in a Slim PHP API - I'm looking for some guidance from senior/experienced developers as to how to proceed.
I currently have an open API, where users can perform get requests with query parameters such as device and date-time range to pull data. I also have devices which are POSTing data, with no authentication. We're not in production yet, but obviously this is bad.
To tackle this, I've been looking at implementing stateless authentication on the GET requests in the first case, specifically using JWT. I initially thought about passing the JWT through as a query string, with options for resetting a token performed through the web front-end after a user has logged in. However, I can see this being bad for man-in-the-middle attacks and my token being exposed (if using plain http). If I was to make sure all get/post requests were performed as https requests, will this be sufficiently secure?
What seems to be the more secure way would be to pass the token through the header. But from what I understand about this, you'd need something like Postman to be able to send requests, which isn't really an option since my users want to access the data using their browser only.
It's pointless using http, https is a must otherwise everyone in between the user and your server will see the password the responses can even be cached.
The token can be stored in a secure cookie which the browser will automatically include with each request. (The Slim Middleware for JWT has this functionality built in). Check out many available libraries at https://jwt.io/
Adding the token to the query string isn't needed if you use cookies, I would not recommend adding tokens to the query string as they are to easily leaked.
(Users love copy&pasting URLs to each other, this would also leak the token)
Note: If you're not sure if JWT is right for you, check out: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/
A user logs in using default Laravel authentication, which puts an encrypted cookie in the browser, and saves the session in the database.
The user moves to a classic asp page, where I check the cookie value, get the hash, and call the laravel app back passing the session id hash.
Then I use that in laravel to see if there's an active session for that id, and if so I return true, so the user can be logged in, in classic asp.
On each page request in the classic app, I check the last_updated_time in the db and update it on each page. All logging in and out is done in laravel, and classic relies on the database to see if a session is active.
I would also call a public url to get sessions variables and add session variables using laravel, since it's all encrypted and using classic asp for this would be hard.
The only risk I see is session highjacking, but I don't think it's a higher risk than usual.
Is it important to lockdown the laravel URL I call to check if it's a valid session?
Am I missing a security hole here?
Is this method secure?
From what you've stated you probably haven't opened up any security holes. The session cookie is not itself encrypted on the users machine, but you are making sure it is encrypted between their machines and yours, as well as between each of your machines. You should make sure you've set the Secure Flag to help prevent the cookie being accidentally sent over traditional unencrypted transport (HTTP), but as stated, this doesn't effect storing the cookie itself.
That being said, you are essentially hijacking your own users sessions. While a hole might not be introduced now, you are potentially weakening the overall system, which could lead to hole in the future.
Is there a better way to do it?
This might well be a dumb question, but are you sure you need the session? If you're juggling credentials between servers, it sounds more like you want to use Access Tokens and scrap the session.
Using Access Tokens is similar to using sessions, but you need to make your services stateless. This means your no longer storing information about the logged in user any specific machine so you'll need to pull anything you need from the database every time they hit a server requiring that information.
This is a good thing in the long run as it's much easier to scale your services when you don't need to worry so much about where the session is and what's inside it.
OAuth 2.0 is widely used standard (Facebook, Twitter, Google), and was specifically designed to be easy to use. The RFC is complex, but there's a log of good guides out there don't worry.
The one slight down side (if you can call it that) to OAuth 2, is that it MUST happen over an encrypted connection. If your use case can not guarantee encryption over SSL or (preferably) TLS, then you should use OAuth 1.0 (WITH revision A) instead.
This is due to the fact that OAuth 2.0 exposes it's "secret" token in requests, where as OAuth 1.0 only ever uses it to provide a signature hash. If you take this route it's advisable to use someone else's library as the hash is very, specific.
Further Improvement
(Note: This section added after the answer was accepted)
One system I've been exploring recently is Json Web Tokens. These store information about the user to save each machine repeatedly looking it up in a database. Because the token is hashed with a secret, you can be sure that, so long as your secret isn't exposed, a valid token represents a successfully logged in user, without having to touch the database.
You should avoid putting anything too personal in the tokens if possible. If you must store private or secret information in the token, you can encrypt it, or you can use a reverse caching proxy to exchange the JWT for a traditional security token. This may initially seem to defeat the purpose, but it means some of your services may not need database access at all.
I'm no security expert but I don't see an issue with this. The packaged Laravel database session handler works the same way. The cookie contains a hash that references a record in the database. The session data is base64 encoded but that's neither here nor there. I think you could actually avoid rolling your own and just use Laravel's DatabaseSessionHandler.
Illuminate/Session/DatabaseSessionHandler
... I just read a little deeper into your question and noticed the part about the public URL to set and retrieve session data. I think this is a really bad idea. Mostly because it will provide an open door to the end user allowing them to read and write session data. This can only end badly.
Like I said above, the data is only base64 encoded so I believe you'll be able to parse, read and write that to your hearts content within asp.
Edit
Ok... I think this is the last edit. The data is php serialized and then base64 encoded. This question looks like it may help you to that end. If it doesn't and an API endpoint is the only way, find some way to block the end user from accessing it.
Aside from session-hijacking, no. This is the standard way applications interact on a internal basis. Of course there might be a better way to get at the data if you choose a different type of session store other than your database, Memcached for instance.
There are couple of things that can be done.
Make the channel HTTPS. It will make almost impossible to sniff on your transport layer.
Rather than making interactions with your cookie, you could use a JWT to get this task done. Which will help you to use the existing functionality in your system while connecting with ASP system as well. You can write a small REST web service which allows ASP to connect. You could use this lib. You can refer this article which will give you an idea how it should be done.
Please let me know if you need more information.
I've created a forum which uses a PHP session when logged in to determine the user id, and cookies for log-term login.
I suppose I have two questions:
Is this the best/securest method?
Cookies can be added manually via the address bar with javascript, which is a huge security risk. Is there any way around this?
Thanks!
First, make sure you are using https and not http. This will keep your traffic from getting sniffed and exploited.
Secondly, generate as random a value as possible to use as a token in the cookie. This is how many of the big sites do their user tracking. Have a map of token to user on the server side that tracks the identities. Remember: Anything that comes from the client is untrusted and could be tampered with.
Third, use an HMAC to make tampering much more difficult. You don't want users being able to brute force other tokens.
EDIT:
You may find these other SO questions/answers helpful as you build this system:
Long details about creating and using tokens (doesn't necessarily have to be a REST service to be applicable): REST Web Service authentication token implementation
Creating good tokens (don't use microtime): Is using microtime() to generate password-reset tokens bad practice
I have a PHP application that relies extensively on sessions. We are now considering building an API for our users. Our initial thoughts are that users will need to authenticate against the api with their email address, password and an API key (unique for each user).
However, as the current application (including the models) relies on user sessions extensively, I am not sure on the best approach.
Assuming that an API request is correctly authenticated, would it be acceptable to:
Start the session for the API call once user is authenticated
Run the models and return json/xml to the user
Kill the session
This means that the session gets instantiated for each API call, and then immediately flushed. Is this OK? Or should we be considering other alternatives?
In my experience of creating APIs, I have found it best that sessions only last for one request and to recreate the session information in each execution cycle.
This does obviously introduce an overhead if your session instantiation is significant, however if you're just checking credentials against a database it should be OK. Plus, you should be able to cache any of the heavy lifting in something like APC or memcache based on a user identifier rather than session reducing the work required to recreate a session while ensuring authentication verified in each request.
I have website w1 written in rails using auhtlogic for authentication and w2 in PHP(say), I want w2 to access session information stored by w2 and login user into w2 and also retrieve user_id from session.
By default, Rack (which Rails uses to manage its sessions) stores session information in cookies by marshalling the session hash (see here), which results in a string that is specific to Ruby. It would be extremely difficult to use PHP to deserialize this information.
If you're dead set on doing this, you're going to have to handle the session serialization yourself. I think a full solution is outside the scope of a single question on SO, but a few pointers:
It would be wise to store only a session id in the cookie, and then keep the actual session data in a database that would be accessible from both the PHP and Rails apps. If you really want to keep the session information in a cookie (or in another place like memcached, where you'd also have to serialize it), look into serialization strategies that work across languages, like MessagePack.
You'll want to do something to ensure that the cookie is not tampered with by the user. Rack uses HMAC, which is a good solution. I've never used PHP, but I'm sure they also have a library for it.
You probably already know this, but just in case: This is all assuming that your two apps are sharing the same domain name. If they're not, then your users' browsers won't share the cookie between the two apps, and there's not really anything you can do. For example, you could share sessions between railsapp.yourdomain.com and phpapp.yourdomain.com, but not railsapp.com and phpapp.com.
Good luck!
i tried a solution sometime ago that was more a hack, but for my propose it worked.
after login, i used to write the user's cookie in a file in a public directory and when this user tried to access the other server where he had to access too, my application on this second server, just had to "know how to access" the remote file stored in the first server and load this content as cookie. I did used CURL at that time.
Note that it introduce some security breaches, and probably your security will rely on "obscurity" - for example, the algorithm to mount the file name where the cookie is stored and how to access it and any external webserver configuration.. Said that, i think we could think as well use a shared memcached to store the cookies..
Have you considered using Open ID?