I am currently developing a small application with a couple of endpoints in nodejs and an angularjs frontend.
At the moment I have an endpoint for users and another one for events. The thing is, I was thinking of making all the GET methods require auth, so that someone that isn't logged in can't access the system, for that I thought of using PassportJS.
Anyways, my question/s would be the following:
What auth strategy should I use? Basic, OAuth or another? Why would that be? I mean, I understand how their flow works, but I don't know why one or another would be appropiate for my app.
Should the endpoints require auth or should it check cookies/token or something else in the session? I'm completely new to this, so I don't even know if this question makes sense.
In any case, I would appreciate any overall insight in the topic since I don't have any experience in developing applications with auth and security.
Thanks!
You have to provide more details about your authentication needs in order for someone to give you a definitive answer to this broad question.
Based on your question, one can assume you don't have any requirements though, therefore I could suggest JWT (JSON Web Tokens - https://jwt.io/)
There are nodejs libraries that can help you create, decode, verify JWT tokens. (such as jsonwebtoken). You can find more details about it on github.
Once someone is logged in, you could pass this generated token back to the client which could store it in the browser's session.
The token can be used in subsequent requests by appending it in the request header.
On the server side, you can add a custom auth middleware to the routes that require authentication, which will verify the token's validity and call the next middleware for the current route.
Related
Hi guys I'm recently building a web app, which is basically a shopping site. Security is one of my major concerns. I'm gonna use JWTs (access token & refresh token).
I'm gonna implement it this way: the server will return both access token and refresh token to a logged in user. And for the front end, I'm using React, so I'm gonna save the access token(short lived) in memory(like React context). I'm thinking about store the refresh token(long lived) in cookie, so I'm wondering is there a way for a hacker to extract the cookie and then use it on some clients like Postman and send requests to get access token and write some Javascript to get the access token?
Maybe think of keeping both of these tokens in memory? If you want your user to be still logged in when they come back to your application, you can rely on an SSO session that will log them in seamlessly, instead of using a refresh token in the background.
Have a look at these SPA security best practices. Also I would recommend not to use JWTs as access and refresh tokens, so that no one can read the data that is kept in your JWTs. You can use Token Introspection in your APIs or implement a Phantom Token Approach instead.
Have a look also at this document by W3C which gives some guidelines on security settings you can use for your application.
Your question does not sound stupid at all! It is a great question. There is a way for a hacker to extract the cookie yes. Cookie stealing is a known security issue.
However the way to stop this issue is by enabling CORS that blocks any cross origin API manipulation. By doing this you create a whitelist enabling your web app's URL.
I would recommend disabling this on your development server to enable localhost for faster development, and then enabling it on production.
Here is some starting documentation on CORS: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
Happy coding!
There is a lot of examples how to implement OpenID Connect auth. in Node - code grant (+ client password).
There is a lot of examples how to implement OpenID in React (SPA) - code grant with PKCE
Even I know that PKCE it's rather secure, however I feel bad to relegate authentication solely on client side.
Every React SPA has backend (at least it should be hosted somewhere).
I want to have server side in Node (Express) to securely save client password and make all heavy lifting with Identity Server and
React for front-end.
As I already said there is a lot of examples of "Node (Express) with template engines" for authentication.
But I want to use React as "template engine".
So, I am looking for full and correct implementation of it. Meanwhile I cannot find it.
Can anybody help me with it - to find an example?
You need some actual protection in the SPA / browser though, and the 2 common options are:
Plug in OIDC Client Library to do the heavy lifting, so that you don't write much security code yourself. This library runs a number of strict security checks before accepting tokens.
Use a proxying solution that results in your SPA getting a cookie.
For an SPA this tends to be a more of a home grown solution rather than a standards based one
RESOURCES OF MINE FOR OPTION 1
SPA Security Code
Explanatory Notes
FOR OPTION 2
You could use the Open Id Client Node JS Library server side, and follow it's guidance.
I've found 2 solution on the Internet.
The First :
Implement social authentication with React + RESTful API
On the frontend, get the 3rd party app’s login popup to appear.
(Still on the frontend) Grab the authentication token the 3rd party app returns after >agreeing to login.
(Yep, still frontend) Send that token to the backend as part of the body of your >request. (I like to use Blobs, but that’s just me.)
On the backend, verify the token.
If the token is authentic, you will receive the user as part of the verification >response (at least that’s the case with Passport.js, which we’ll be using).
Save the user’s data to your database.
Return a JWT token to the frontend. What you do with that token is out of scope for >this tutorial, but it should probably be used to authenticate each of the logged in >user’s actions.
Very well explained, with github working example social-auth-example
It's only for social authentications, but I think no problem to make something more general or at least to add my OpenID Connect Auth. provider.
The second example:
React Authentication with Twitter, Google, Facebook and Github
This approach uses socket.io. Very interesting.
P.S.
So, I need to figure out what solution is more secure and if there any security breaches.
Not easy task to do. It's so pity, there is no standard flow for my problem. I can find 1000 reasons why it's better to make all heavy lifting on back-end and not to rely on OIDC Client Library. The first reason is my boss :)
I have just started learning authorization and authentication in react, and I'm writing this after finishing my first simple login system using JWT, as most of you know you store a token in the browser and then you compare it with the saved tokens in your backend now when that validation is done truly I set Authenticated Boolean to true and gain access to the website, after finishing that simple system I checked react dev tools and I found out that I can just change the boolean to true and bypass all of the authentication work!
And I have searched online for resources and tutorials to fix that massive problem but didn't find what was I looking for all I found is how to setup Authentication or protect a router similar to the way I did, but not deeply secured.
So can anyone recommend a course or tutorial paid or free to learn more about security and authentication?
Since React apps are single page apps (if you are doing client-side rendering), the entire application (all html/css/js files) is sent to the client in the initial request. Generally authentication works in the way you have stated where the authentication status of the user is stored in the application state. This, of course, means that someone familiar with web applications would be able to set the variable isAuthenticated to true. If you have sensitive information kept statically (written literally in html/css/js) then this would be an issue.
The reason this scenario is not generally seen as an issue is because React apps usually do not hold any data. And data is usually the sensitive stuff in an app. Data can be tied to the user and should not be exposed to those who are not properly authenticated or do not have the required permissions. Data is held by the server, which can control what it sends out (checking for verified JWTs) via the API to the app. So your server should check for a valid JWT on any request that returns sensitive information—generally all requests except those for the app itself and authentication requests.
In short: Yes, someone can get access to the "authenticated" side of your app, but any requests to the API for data by the app at this point would (or should) be blocked as unauthorized (i.e. status 401). So they can see what the app looks like to an authenticated user, but would not be able to see any sensitive information.
(Note: if you do store sensitive information statically (as mentioned above), consider storing it on the server and having the app request that info via the API and requiring a valid authentication token).
If you would like to block the possibility of an unauthenticated user gaining access to the authenticated side of your app, you could make the login page its own app or HTML doc and only send the full/authenticated version of the app to authenticated users.
I am new to React.js and have a need to maintain session of the application...lets say for 3 minutes.
Authentication is done by a third party (akamai) and i need to have the session management. Can someone guide me on this? Any github code/video? TIA
Typically I would not recommend you manage sessions on the front-end as it's easy to hack.
With JWT (JSON Web Tokens) you create a token on your backend and your front-end just requests the latest token. Inside that token will be info on whether that session is still active (you'd control what is returned).
Find a good JWT guide set it up, then from React you make a simple fetch command to get the JWT and then parse it and boot the user as necessary.
There was a similar question to yours asked earlier in the year, please see below:
What is the best way to manage a user's session in React?
I'm working on a webapp that will allow users to authenticate using simpleauth. For now I will be supporting Google and Facebook. Other than logging in and out (using webapp2), the webapp will consist of Cloud Endpoint APIs. The clients will be web, Android, and iOS.
My questions is, using Endpoints Proto Datastore, can I have user_required=True and call endpoints.get_current_user() to get my user from an #Model.method if the user's auth provider is Facebook (or any of the other supported OAuth2 providers? If it is not possible, does that mean I should not have user_required=True, and should instead get a permanent user id from the provider given the OAuth2 token and keep it in the datastore, generate my own auth token for that user, and then pass that token to each request?
EDIT: Instead of passing the auth token around, would it make sense to have an authenticated user request an "API token" that they can pass to the API methods? Would this token have to be included in the POST or GET body, or can it be put in a header/cookie (I saw some questions elsewhere on SO regarding headers and cookies with Cloud Endpoints, but it's been some time since then). This is all assuming that non-Google auth won't work.
This answer is not going to directly answer your question but should give you a good idea how you can implement authentication in a safe way. I've implemented something similar recently and spent quite some time figuring out which is the best way to do authentication with Google AppEngine environment.
Google supports OpenId Connect protocol. Facebook's implementation should be very similar according to Getting Started with OAuth 2.0 book. I will focus more on Google's implementation, as I am more familiar with it but the concepts should be very similar when using other OAuth providers.
OpenId Connect will give you an id_token, after successfully authenticating the user. It will also give you an access token. Access token is something that should be kept a secret. Never send it over the wire. Id token on the other hand is very handy. It contains some information about your user, and it's encrypted so it doesn't expose any information about the user "just like that". You'd have to crack the id_token to find out anything about user. In the unlikely event that it gets cracked it doesn't expose anything critical about the user. What you can do you can store it as a cookie and then use it in all subsequent requests to verify it the user by checking if there's an access token that matches the id_token. The only drawback is that id_token is quite long - it takes around 650bytes. That would mean that every http request carries that payload. If sending that much information is too much for your use case you can send only first few characters, maybe 12 or so and then match just the first part. The id_token has can also be useful when analysing your data. It will show up when analysing http requests but will not reveal any information about the user and you can still differentiate requests that came from different users.
Also on a side note, don't try using AppEngine's users service as it doesn't work very well with any kind of custom authentication.
Hope this gives you an idea and puts you on the right track.