I am trying to understand how to implement password reset / forgot implementations using AngularJS (1.x) with Nodejs backend. I've read this great post on the backend part for Nodejs. I then read this SO post related to Angular and UI Router. I then read this SO post, again related to Angular and forgot password.
Tokens
I know for authentication in Angular, it deals with tokens. It seems that there are 2 main ways to create tokens, JWT and passport-jwt. Is one better over the other?
Confused about
Password Reset and Forgot functionality, from what I've read (and hopefully understand), are mostly performed server-side with just a little bit done on client side (what is the little bit?).
What exactly is performed on the client side when it comes to Password Reset and Forgot? What roles does/would AngularJS play in those 2 features? Is it possible to have AngularJS integrated somehow for those 2 features?
I know for authentication in Angular, it deals with tokens. It seems
that there are 2 main ways to create tokens, JWT and passport-jwt. Is
one better over the other?
People here will definitely parse your use of the word "better" as it is a highly subjective term. Either way, in my experience, the best implementation is often the simplest one. When I need to wire up some simple authentication, I like to use jwt-simple and tend to think passport can be overkill. The most important thing when implementing authentication when using JSON web tokens is understanding the general concept behind it. It can be a bit confusing at first, but once you "get" it, its really quite straightforward.
What exactly is performed on the client side when it comes to Password
Reset and Forgot?
On the client side, the old JSON web token – with the old/forgotten password – would need to be removed and replaced with the new one.
What roles does/would AngularJS play in those 2 features? Is it
possible to have AngularJS integrated somehow for those 2 features?
All Angularjs – and really, any frontend code – handles in this process is the replacement of the JSON Web Token on the frontend.
Related
Here at work we have a portal with like 6 systems lying under, each one has its own backend API, built with .NET Core, the frontend is React by the way.
The situation :
Today we have a single API that is used for both Authentication and Authorization (i will call it LoginAndProfileAPI) and its is used globally for all of the systems, here's my attempt to describe how it works :
As Is
we have this global,
The Issue :
Now we have a necessity to have local user management inside each system so that the local admins for that system can manage the access level/permission/profiles only of the profiles related to that application, we also need to turn our Auth process a little bit more standard, separating Authorization and Authentication a little bit more.
What would you guys do in this situation, what i came across until now was :
The idea i had, but stil needs some shape
but it kinda looks like a mess tho.
Does anyone have a clue of how can i be more standard with this
Edit :
Would that be best scenario ?
Looks pretty much like a more minimalistic/lightweight approach !!!
#WandererAboveTheSea suggestion about it
(did i get it right ?)
Here is a cleaner image :
JWT Auth Example
What looked kinda odd to me was that it seems like JWT is beeing used for both Authentication and Authorization
JWT is meant to be stateless and lite weight. Your using JWT for authorization is the correct approach.
You can improve on the following part.
After getting the username you are making database calls to get the user profile which you can avoid by adding those details to JWT itself. So that part can be simplified.
Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties.
Apart from this rest of the design looks good.
As a school assignment I have to make the following:
Overview
Create a React SPA which does the following:
Authenticates against (Welcome to the IdentityServer4 demo site) using the authorization code flow with PKCE
Calls (test) using the correct token
Detail
Create a SPA in React. Usage of React is mandatory this time.
add a library which adds OIDC protocol support to the SPA. Make sure the authorization code flow with PKCE is supported
use (Welcome to the IdentityServer4 demo site)as your authorization server. This authorization server supports the authorization code flow with PKCE
call (test) using the correct token and show the results back to the user
host the react app on Netlify
As a beginner in this field, I totally don’t understand the assignment. Can anybody help me out?
Edit - welcome to SO! Be nice here and help other people.
In the interest of being nice, here are some pointers and a solution to your assignment. But please, please, please - don't just copy it, learn how it works, think it through, apply it to your own react app.
First of all, while identityserver has very good documentation at https://identityserver4.readthedocs.io/ - it is very code-oriented and might be hard to start with.
So instead, take a look aut Auth0, a competing commercial product. They have pretty good docs as well, and they explain some of the protocols too.
https://auth0.com/docs/protocols/oauth2
https://auth0.com/docs/flows/concepts/auth-code-pkce
These are of particular interest.
Now, they also have scenarios like the one you need to implement. You might think it's this one: https://auth0.com/docs/architecture-scenarios/spa-api but they are a little behind in the new guidelines (but luckily your assignment isn't) that SPA's should also use code flow with PKCE, so you're better off with this: https://auth0.com/docs/architecture-scenarios/mobile-api
(more on why this is better here: https://brockallen.com/2019/01/03/the-state-of-the-implicit-flow-in-oauth2/)
Having read all that, you need to find a good JS library that does oidc/oauth for you. No use in writing one yourself in school unless you're going for a Phd.
Google javascript oidc -> https://github.com/IdentityModel/oidc-client-js comes up. Hey! It's those guys from identityserver again. They're great people, aren't they? They've certainly got your back.
Now google react oidc-client-js - well isn't that nice, someone beat you to it: https://github.com/skoruba/react-oidc-client-js
That should get you started. Like I said, please don't make me regret this and take the trouble and time to actually learn this stuff. It could lead to an interesting line of work later on :-)
I'm still very new to React so forgive me if the question is too naive. To my understand, React usually requires an API to do XHR requests. So someone with very basic tech background can easily figure out what the api looks like by looking at the network tab in web browser's debug console.
For example, people might find a page that calls to api https://www.example.com/product/1, then they can just do brute force scraping on product id 1 - 10000 to get data for all products.
https://www.example.com/api/v1/product/1
https://www.example.com/api/v1/product/2
https://www.example.com/api/v1/product/3
https://www.example.com/api/v1/product/4
https://www.example.com/api/v1/product/5
https://www.example.com/api/v1/product/6
...
Even with user auth, one can just use same cookie or token when they login to make the call and get the data.
So what is the best way to prevent scraping on React app? or maybe the api shouldn't be designed as such, hence I'm just asking the wrong question?
Here are some suggestions to address the issue you're facing:
This is a common problem. You need to solve it by using id's that are GUID's and not sequentially generated integers.
Restricting to the same-origin won't work because someone can make a request through Postman or Insomnia or Curl.
You can also introduce rate-limiting
In addition, you can invalidate your token after a certain number of requests or require it to be renewed after every 10 requests
I think no matter what you do to the JavaScript code, reading your API endpoint is the easiest thing in the world(Wireshark is an easy, bad example), once it is called upon from the browser. Expect it to be public, with that said, protecting it it is easier than you might anticipate.
Access-Control-Allow-Origin is your friend
Only allow requests to come from given urls. This may or may not allow GET requests but it will always allow direct access on GET routes. Keep that in mind.
PHP Example
$origin = $_SERVER['HTTP_ORIGIN'];
$allowed_domains = [
'http://mysite1.com',
'https://www.mysite2.com',
'http://www.mysite2.com',
];
if (in_array($origin, $allowed_domains)) {
header('Access-Control-Allow-Origin: ' . $origin);
}
Use some form of token that can be validated
This is another conventional approach, and you can find more about this here: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
Cheers!
Contemplating building an Angular 2 front-end to my website. My question is not necessarily related to Angular but I want to provide full context.
Application logic that displays content to user would shift to the client. So on the server side, I would need to expose data via a RESTful JSON feed. What worries me, is that someone can completely bypass my front-end and execute requests to the service with various parameters, effectively scraping my database. I realize some of this is possible by scraping HTML but exposing a service with nicely formatted data is just a no-brainer.
Is there a way to protect the RESTful service from this? In other words, is there a way to ensure such service would only respond to my Angular 2 application call? Authentication certainly isn't a solution here - I don't want to force visitors to authenticate and the scraper could very well authenticate and get access, anyway.
I would recommend JWT Authorization. One such implementation is OAuth. Basically you get a json web token ( JWT ) that has been signed by an authority you trust that tells about the user and what resources they can access on your api.
If the request doesn't include an Authorization token - your API rejects it.
If the token has been tampered with by someone trying to grant themselves privledges after the token is signed by the authorization authority - your API rejects it.
It is a pretty cool piece of kit.
This site has information about OAuth implementations in different languages, hopefully your favorite is listed.
Some light bed time reading.
There is no obvious way to do it that I know of, but a lot of people seem to be looking at Amazon S3 as a model. If you put credentials in your client code, then anyone getting the client code can see them. I might suggest that you could write the server to pass a time limited token back to the browser with the client code. The client code would be required to pass it back to the server for access. This would prevent anyone from writing their own client code, as only client code sent by the server would work, though only for some period of time. The user might occasionally get timeouts, but that depends on how strict you want to make the token timeouts. Of course, even this kind of thing could be hacked by someone making a client request to get a copy of the token to use with their own client API, but at that point you should be proud that someone is trying so hard to use your API! I have not tried to write such a thing, so I don't have any practical experience with the issue. I myself have wondered about it, but also don't have enough experience with this architecture to see what, if anything, others have been doing. What do angularJS forums suggest?
Additional References: Best Practices for securing a REST API / web service
I believe the answer is "No".
You could do some security by obscurity type stuff. Your rest API could expose garbled data and you could have some function that was "hidden" in your code un-garble it. Though obviously this isn't fool proof, but if you expose data on a public site it's out there regardless of server or client rendering.
I've been putting together a single-page application using React and React-Router and I can't seem to understand how these applications can be secured.
I found a nice clear blog post which shows one approach, but it doesn't look very secure to me. Basically, the approach presented in that post is to restrict rendering of components which the user is not authorized to access. The author wrote a couple more posts which are variations on the idea, extending it to React-Router routes and other components, but at their hearts all these approaches seem to rely on the same flawed idea: the client-side code decides what to do based on data in the store at the time the components are composed. And that seems like a problem to me - what's to stop an enterprising hacker from messing around with the code to get access to stuff?
I've thought of three different approaches, none of which I'm very happy with:
I could certainly write my authorization code in such a way that the client-side code is constantly checking with the server for authorization, but that seems wasteful.
I could set the application up so that modules are pushed to the client from the server only after the server has verified that the client has authority to access that code. But that seems to involve breaking my code up into a million little modules instead of a nice, monolithic bundle (I'm using browserify).
Some system of server-side rendering might work, which would ensure that the user could only see pages for which the server has decided they have authority to see. But that seems complicated and also seems like a step backward (I could just write a traditional web app if I wanted the server to do everything).
So, what is the best approach? How have other people solved this problem?
If you’re trying to protect the code itself, it seems that any approach that either sends that code to the client, or sends the code able to load that code, would be a problem. Therefore even traditional simple approaches with code splitting might be problematic here, as they reveal the filename for the bundle. You could protect it by requiring a cookie on the server, but this seems like a lot of fuss.
If hiding the internal code from unauthorized users is a requirement for your application, I would recommend splitting it into two separate apps with separate bundles. Going from one to another would require a separate request but this seems to be consistent with what you want to accomplish.
Great question. I'm not aware of any absolute best practices floating around out there that seem to outstrip others, so I'll just provide a few tips/thoughts here:
a remote API should handle the actual auth, of course.
sessions need to be shared, so a store like redis is usually a good idea, esp. for fast reads.
if you're doing server-side rendering that involves hydration, you'll need a way to share the session state between server and client. See the link below for one way to do universal react
on the client, you could send down a session cookie or JWT token, read it into memory (maybe using redux and keep it in your state tree?) and maybe use middleware (a la redux?) to set it as a header on requests.
on the client, you could also rely on localStorage to save the cookie/JWT
maybe split the code into two bundles, one for auth, one for the actual app logic?
See also:
https://github.com/erikras/react-redux-universal-hot-example for hydration example
https://github.com/erikras/react-redux-universal-hot-example/issues/608
As long as the store does not contain data that the user is not authorized to have, there shouldn't be too much of a problem even if a hacker checks the source and sees modules/links that he shouldn't have access to.
The state inside the store as well as critical logic would come from services and those need to be secured, whether it's an SPA or not; but especially on an SPA.
Also: server-side rendering with Redux isn't too complex. You can read about it here:
http://redux.js.org/docs/recipes/ServerRendering.html
It's basically only used to serve a root html with a predefined state. This further increases security and loading speeds but does not defy the idea behind SPAs.