2FA, if user logs in with a new device with a new device ids OR new IP we need to send them a otp via email to validate.
Consider using Kong for authentication layer. We don't write our own crypto, so why should we write our own auth?
Q: Is there no API root at /? I think this is best practice for public APIs - not sure for ours.
Authentication TODO: Endpoint to take in username & password -> output JWT for inclusion in subsequent requests as a 'x-access-token' header. https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens#authenticating-and-creating-a-token
Explain Kong: https://getkong.org/about/faq/#how-does-it-work
https://github.com/PGBI/kong-dashboard
In the future, we can easily add oauth consent third party flow https://getkong.org/plugins/oauth2-authentication/
https://github.com/Mashape/kong-oauth2-hello-world
In Kong, A consumer can have many credentials.
For username+password auth, we can use: https://getkong.org/plugins/basic-authentication/, can provision new credentials too.
For facebook/google auth, we can use https://getkong.org/plugins/jwt/
If we roll out our own authserv, we'll need to use http://passportjs.org/docs, and on valid credentials return a JSON web token that all other microservices consume to proceed. We also need to move out the database tables for Local.js, Facebook.js, and Google.js.
Q: What's the relationship between User.js and these credential objects?
Ask Sai to handle staging/production deployment: https://getkong.org/install/
http://aws.amazon.com/documentation/apigateway/
http://docs.aws.amazon.com/apigateway/latest/developerguide/getting-started-intro.html
Check out and compare AWS API Gateway and compare with Kong.
Kong is an API proxy/middleware with a configuration RESTful API, lets all calls through this proxy be authenticated beforehand.
Check if ids right now use autoincrement or uuids.
Read https://getkong.org/docs/0.5.x/proxy/
Kong basic concepts:
request_path method, we can route all our /meal queries to a meal microservice.
For reset password flows we will need to reprovision credentials on Kong as well.
Q: Are we using Cassandra anywhere currently? Kong uses a Cassandra cluster as primary storage, which we can provision ourselves via AWS or Instaclustr.
The Kong Server, built on top of NGINX, is the server that will actually process the API requests and execute the configured plugins to provide additional functionalities to the underlying APIs before proxying the request to the final destination.
Drawback of Kong: writing custom functionality must be through Lua plugins. https://getkong.org/docs/0.5.x/plugin-development/
Right now the API is NOT STATELESS! Authenticated status is kept in req.session.authenticated instead of say, as a JWT passed into the request Header
Other than EC2, what other AWS services are we using or plan on using? This will greatly influence which Kong or AWS API Gateway we use -> A LOT of services.
AWS API Gateway has an admin GUI and SDK generation built-in.
AWS is NOT extensible.
AWS API Gateway's authentication schemes are limited to AWS credentials. Tokens and oauth can only be forwarded to the backend for the services themselves to handle...
Kong seems more suitable for public APIs where there may be a large number of users.
leaning towards Kong, as AWS API Gateway has far fewer features and is not as extensible.
AWS Setup Image for https://getkong.org/install/aws-marketplace/
We should also consider:
We also need to find a way to validate/test our integration :)
The API Gateway need to handle some requests by simply routing them to the appropriate back-end service. It handles other requests by invoking multiple back-end services and aggregating the results.
There's also https://docs.strongloop.com/display/LGW/StrongLoop+API+Gateway, but it seems to be primary for Node.js
AWS API Gateway fits our requirements better, although I'm still not sure if combining responses from multiple microservices is possible.
AWS API Gateway also has more straightforward testing utilities.
Example microservice: https://auth0.com/blog/2015/09/04/an-introduction-to-microservices-part-1/
Trying out https://tyk.io/
Q: Why separate Local.js (Local Login Credentals) and User.js? Similarly, we seem to have 'Facebook.js' and 'Google.js' models to capture oauth return callback parameters.
A: keep user information separate: authentication, billing, and identity information should all be in separate services with separate databases.
Q: Is there a reason why we're not using Passport.js for authentication?