Is it possible to create more API endpoints on servers to share a different set of user data?
If yes, what type of user-specific Authorization can be used to protect these APIs (without adding any new admin API keys or another authorization method)?
Is it possible to connect the client application to multiple Server applications? How?
Is it possible to connect one more (or 2nd) client application to the Server for login?
If yes, please list down the detailed steps for the changes you will have to make in the Server application to support multiple clients.
Also, list down if any changes need to be made in the client applications.
Is it possible to share complete data for few client applications and limited data for the rest of the application? How do you achieve this?
e.g. client 1 only needs email & phone, but client 2 needs email, phone, birth date and address of the user.
Yes You can create more API endpoint, you can use JWT verification for each client Users.
what is the purpose of multiple server application? can you elaborate more !
As i mention in 1st answer, search more about 'jwt authentication in nodejs' for multiple users, so every user can use same API for login.
Yes it's possible based on client's role, or if client/user don't have specific role, but client 1 need only email,phone and client 2 needs all the data. Then best solution is to implement 'GraphQL in nodejs' it will solve your problem
Related
Our application is a Single Page App built with Angular and ASP.NET Core.
We have to integrate another web app which we will integrate in an iframe in our app. This app has to send data back to our application after the user finished his work.
I need to make sure, i can relate the data coming from this application to an authenticated user starting the operation in our app in a secure way.
Those were the options i thought in realizing the interface:
Generate a unique token in our application which knows about the related user and gets passed to the other application. The other application transmits this token along with it's other data back to our application and we can check this token on our backend to find out if it's a legitimate request and also relate it to a user.
Store cookies after authenticating the user in our app, so the other app could just post the data to our endpoint and the cookies make sure, the call takes place in the authenticated user's context. Also we would probably have to allow CORS from this site to make this work.
Use a non-http-based middleware (message broker) to connect the systems in a way, which keeps data transfer out of the browser.
Transmit the Bearer token from our application to the other application, so the other application can make an authenticated call to our application backend.
CORS would have to be activated as well for the other app's origin.
However i'm a bit concerned about the security implications this could have.
Which way would you suggest? Or would you suggest a completely other way of achieving the goal?
Thank you very much for any advise!
Number 2 and 4 will both have potential security issues. Passing authentication contexts between different applications should be avoided, instead each application should be authenticated independently.
Number 3 would add complexity to your architecture while bringing little to no benefit for your use case - message brokers are not trivial to configure and operate. I would also question why two apps need to be integrated in the client via and iFrame but then are somehow able to share a message broker.
Number 1 for me is the cleanest option from your ideas. Consider however, you will need to pass this token somehow in the client which may open security holes. Think about the negative implications of what could happen, should a nefarious 3rd party get access to this token.
In your place I would question why an iFrame. Would it be possible for your app to provide the UI and instead communicate with this other application over an API?
(Tom Vaga asked a similar question here but Luke's response didn't quite address what I'd hoped to accomplish... I'd comment there but don't have the points yet :-) Thanks! )
I've got a Slim server working well to register and authenticate users for our API, using JWT, allowing only 'authenticated' users to access certain api endpoints.
I'm now trying to setup a SocketCluster for various realtime messaging parts of the app, and I would like to restrict subscriptions to only authenticated users. I may be missing a part of the concept, but is it not possible to use the token-cookie set successfully by Slim to also authenticate to SocketCluster? (ideally using the built-in authentication process, and without having to call-back to the slim-api?) They're on different servers as sub-domains... Would I have to insert the same secret into the SocketCluster configuration somewhere?
Thank you!
Given an Node.js app making use of Mobile Application Security - I want to get a unique identifier from the request based on the client making the call. So for example, my hybrid mobile app authenticates with Google, sets the security token, makes the call to my Node.js app. All of this works fine, but I'd like to associate a unique ID with the client so that when I do operations like data fetching, I can use the token as an identifier. Is that possible out of the box or do I need to include it in my calls?
Unfortunately, this is a limitation of MAS and the hybrid SDK. You will need to implement that functionality yourself.
Apologies for the inconvenience.
We have 3 nodejs web application running on same domain name on same vps with multiple subdomains and implementing passport authentication for each. We wanted single user be able to access all application with single account and for that we have added accounts.example.com as fourth application solely for purpose of account management. The requirement is - once user is authenticated in accounts.example.com, how to enable user to access rest of the three web application with that session.
you can share your session in redis-server.if you use express,you can try to use connect-redis
https://github.com/visionmedia/connect-redis
Try Hands on CanSecurity... It tops the chart for node.js Single sign on.. Hope this proves fruitful https://github.com/deitch/cansecurity
I am starting to plan a web-app and Backbone.js will be a perfect fit for the client side. I have been planning on using node for the backend but this is open for the time being.
I need a way to secure the front-end app's connection to a database. I have had discussions with others on Quora but I think the thought process was too abstracted from the core problem.
I would prefer to be accessing the data by RESTful end-points, but I need to ensure only my app can talk to the API. I will have full control over both the front-end and back-end of the application. There is a possibility of other apps being built around the database (in a year or two), however they will be developed by me (i.e. not a public API) and these will probably use separate OAuth end-points.
Some notes on the app (may or may not be useful):
The app is planned to be offered in a SaaS model where companies subscribe and are allowed multiple users.
The data for each company needs to be secure and only accessible to members of that company.
All traffic (front-end and app to API) will be sent through SSL.
Any advice on the best way to do this will be greatly appreciated.
We have the exact same setup as you - SaaS model, multiple apps (mobile, web, etc) and when I followed your link, Miguel has the exact solution we use.
Token that is time stamped and sent to the client on auth. We store that hash token in a User Model and then every subsequent request we validate that token.
You can extend Backbone.Model with a BaseModel that appends the token to every server request by overriding Backbone.Sync
See here about how they extended a baseview and you can apply the same thing to a basemodel.