I am running a php website(www.mywebsite.com). Now I would like to add a real-time chat function so users can chat with others.
I decided to run node.js and socket.io in another server separating from web server(chat.mywebsite.com).
Users who wish to use chat function have to log in through www.mywebsite.com. After login, they will be sent to a chat page (www.mywebsite.com/chat). So on this page the client must post a request to web server for a JWT and use this JWT to authenticate in socket.io.
My question is: if the JWT is stolen by someone else, and pass the JWT to socket.io, it will definitely fake the server that the user is authenticated. So is this approach correct or can you suggest another method for my situation? Thanks!
If someone has access for a JWT token - they basically hijacked his session, https://en.wikipedia.org/wiki/Session_hijacking
As long as you don't have XSS's or other vulns on your website, it shouldn't be something you should worry about.
just make sure that the socket.io does auth the user by using the jwt token before letting him send/recieve messages.
Related
I'm working on an Absinthe GraphQL API for my app. I'm still learning the procedure(so please go easy on me).
I've a Absinthe/GraphQL MyAppWeb.schema.ex file in which I use for my queries and mutations. My question is how do I use this API for authenticating the user on both Mobile and Web app?
How do set a cookie(httpOnly & secure) in my web app and access/refresh tokens in a single Absinthe API to serve my website and mobile app. Basically what I'm trying to learn is how do I authenticate the user based on specific platform.
If my question sounds bit confusing, I would be happy to provide more information related to my question. I would really be grateful if someone could explain the procedure, I've been very stuck on this for a while.
I would avoid using authentication mechanisms provided by absinthe(if there are any). Depending on what front-end you are using, I would go with JSON API authentication. The flow on server goes the following way:
Create a endpoint for login that will receive a user and password and will return a refresh token.
Create a endpoint for exchanging refresh token for access token.
Use a library like guardian to generate your refresh/access tokens.
Create a phoenix plug for authentication that will check your tokens, guardian has some built-in plugs for this.
Now on device you have to implement:
Ability to save refresh and access token on device.
Have a global handler for injecting access token on authorized requests.
Have a global handler for case when access token is expired. (you usually check if your request returns Unauthorized, then you should request a new access token from the server using your refresh token)
This seems like a crude implementation, however I would advise in implementing your system instead of using a black box library that you have no idea how it works under the hood.
How can I authenticate a user with sanctum when the whole login process happens server side? The question I am asking is kind of hard to phrase so I will explain my situation.
I have a Vue SPA for my front end and a Laravel app as a backend api (they run on the same domain). Normally, to authenticate with the laravel api using sanctum, you would send the credentials in a post request, and if the login was successful, you would get the session information returned. However, I want to use steam login for authentication. I already have to whole process on the backend figured out in terms of actually logging in, however I am unsure how to pass the session data back to the SPA. Currently I have a link on my site that takes the user to the login endpoint on the api, and that endpoint will have them authenticate with steam, so the entire login process is handled on the backend. Now I just need to figure out how to send the session data back to the SPA. I guess it world be similar to using sanctum with socialite.
So far I've tried usisng Sanctums Mobile Aplication Authentication. I did this by having the user log in into the laravel app using steam, then once authenticated, a access token for their account would be created, and they would get redirected back to the Vue apps call back file, with the token as a part of the query string. Then the token would be stored and . This worked, however it presented some security issues.
The token was passed back in the url, so anyone could screenshot it and use it
Anyone who obtained the token by some other method could use it.
Here is the code for what I tried: https://gist.github.com/DriedSponge/4e8549486c2bfa33e4c0b21a539bdf85
So in summary, I want the entire login process to take place on the server, but somehow at the same time authenticate the SPA. If you have any ideas on how I can make this work, please let me know. If you have any questions just leave a comment. Thanks in advance.
I have a website which is based on a Laravel backend api and a Nuxt.js frontend app.
The laravel app is served at api.website.com. Till now the api was open, meaning everyone can make a get request. There are almost no post requests.
I know need to implement a login mechanism for the users (Usual login+register and facebook login).
My question is about how would I go to make this process secure. Do I need Laravel Passport (or other similar mechanism)?
My thought is that, say I have an endpoint api.website.com/register (POST), I do not want anyone to be able to just make a post request and create an account. I need to have some sort of security like a csrf token. I know I can use CORS but that doesn't really provide much of security in this case.
You can use jwt like this or laravel passport.
I have a Laravel 5.5 Application that's using the session based auth out of the box. On some of these pages I have react components that need to get/post data from/to an API.
What is the best practice for handling this? Do I simply hide the API endpoints behind the auth? This would work but should I be using Laravel Passport for this instead?
I've had a play with Passport and it seems that this would work but I don't need users to be able to create clients and grant 3rd party applications permission etc. There is just the first party react app consuming the data from inside the laravel application (view).
From my initial experimenting with it, it seems I'd need to have the login call made first to receive an access token to then make further calls. As the user will already be authenticated in the session is there an easier way?
I'm not sure if Passport is intended to be used for this purpose or not. I'd rather take the time to get it right now as I'd like to get the foundations right now if the app scales.
You can proxy authentication with Passport. Using the password grant type users would still log in with their username/password, then behind the scenes make an internal request to Passport to obtain an access token.
Restrict what routes are available when registering in a service provider by passing in:
Passport::routes(function ($router) {
$router->forAccessTokens();
$router->forTransientTokens();
});
That limits access to personal tokens and refresh tokens only. A client will be created when you run php artisan passport:install.
Setup a middleware to merge the password grant client id and secret in with the request, then make a call to the authorization endpoint. Then it's just a matter of returning the encrypted token and observing the Authorization header for requests to your api.
There are SNS application with 2 servers. Web backend server and REST API server.
The web server allows user login/logout with username/password, and show user information
The REST API server provides APIs like /topics, /comments, it should be stateless without session
The REST API will serve other web applications
There are some potential solutions, but neither is security.
Base Auth, the browser hold the username/password
Token with expiry timestamp, the problem is user could stay on the page until token expires
So, is there a way to protect the REST API when calling it from AJAX?
If I have understood your problem correctly I may suggest you use the Token solution. In order to maintain security you may generate new token on every request (& send it to client in response), which should be used to make next request, and disable token if it is once used or has expired.
Sorry, I meant to mention it as a comment, but I don't have enough reputation.