I'm building an application using nodejs express + mongodb.
I need to add authentication.
I've found these options:
using json web tokens
using passport framework
Are my user credentials which I pass over the internet secure if I combine one of these 2 with ssl?
Well, both are secure but different (https is the way).
If you need server side sessions after autentication, go for passport is easy to set up and supports a ton of autentication ways.
In the case of JsonWebTokens, are great way to implement session-less autentication like interacting with a REST API.
This is a good read: If REST applications are supposed to be stateless, how do you manage sessions?
Yes, it will be secure if you do that, you may consider using two-factor authentication if you want to increase security.
json web tokens is just a standard used for token based authentication, while the passport framework is a tool that will help you to build your software in a more secure way. I'm not familiar with Passport Framework, but I believe that all strategies that it provides will use JWT.
TLS (or SSL) is a tunneling protocol to tunnel unsecure http protocol, which sends plain text data to a server. You may be interested in RFC1818 that has some information about using http with tls.
It's very important to tunnel http request when sending sensitive information. It will add to you app:
1) Server authentication
2) Integrity protection
3) Replay protection
4) Confidentiality
Related
I'm new to whole authentication/authorization part in web development. Specifically JWT. So I came across a medium post explaining the fundamentals of JWT. There was a diagram which showed how the web server and authentication server had no direct communication, AFTER a JWT token had been issued by the authentication server.
So, my 3 questions are:
What's the difference between the authentication server and the web server?
Is the authentication server, the database server?
And, since you are going to take user data(e.g password/username) from the
client(browser/user), to which server do you write the code to? authentication or web?
Because NodeJS/Express allows you to write the app server code right?
1 - An auth server is usually part of a microservice architecture, if you do not have to scale you can have a simple authentification middleware in your web server.
2 - The auth server is a server usually part of a microservice architecture which role is to authentificate requests and act as a gateway to the rest of the microservices.
3 - Depends if you want to scale or not. If you want to separate auth and the rest of the apis, there are multiple ways to scale.
Hope it helps =)
What's the difference between the authentication server and the web server?
These are two separate servers. Two different programs, potentially running on two (or more) different machines. With different purposes and responsibilities.
Is the authentication server, the database server?
No. For all you know the auth server may not use db at all. For example it can store all the data directly in files, or even in memory. Although, in practice there will be some db behind it. Auth server is just a server with a special purpose: user authentication (as the name suggests).
And, since you are going to take user data(e.g password/username) from the client(browser/user), to which server do you write the code to? authentication or web? Because NodeJS/Express allows you to write the app server code right?
Write code? Both? Depends on whether you implement the auth server by yourself or not. I'm not sure I get that question.
The point is that user credentials should be send to the auth server and the auth server is responsible for validation, secure storage and token issuing. So that other servers (in particular the one you call "web") don't have to worry about it.
A client of mine has a bunch of APIs in CloudHub that communicate with two APIs on premise in their runtime. The question I get asked, to which I don't really know the answer, is how to secure the communication between the APIs on CloudHub and on premise without using API Manager (since the client preferred not to pay for it) ? I thought of a middleware (middleware inception) that hashes the messages from one end to another, is this a viable idea? What could the best answer be?
The server applications should implement some basic security best practices like authentication and encryption.
Having applications deployed in any cloud environment without security is a big security risk. I assume that there is a secure link between the CloudHub environment and their on premise environment, like a VPN, but even so this architecture would not probably pass a security audit.
They should implement authentication using HTTP Basic authentication or OAuth 2. These are the most common authentication schemas used for REST APIs. Note that credentials go in clear text so they should also implement encryption.
To encrypt the traffic the server applications should use TLS, ie HTTPS connections instead of plain HTTP.
Optionally you could also implement mutual TLS authentication, requiring the client to have a valid certificate that the HTTPS server validates.
Hashing message could be an additional level of security, but that implies changing the applications logic to implement some custom security. The effort should be better put into implementing standard security practices as mentioned. If after that you want to add it feel free to do so.
You have not shared details of the technology of the on prem applications. Mule applications can implement both the client and server side of any of these methods. Read the documentation for details:
https://docs.mulesoft.com/http-connector/1.7/http-authentication
https://docs.mulesoft.com/mule-runtime/4.4/tls-configuration
https://help.mulesoft.com/s/article/Tutorial-how-to-create-a-simple-Mule-4-http-basic-authentication-application
I am developing a backend for a mobile application using Node.js to handle HTTPS requests. I have set up an SSL to connect from the client to the server and was wondering if this was secure enough.
I don't have experience with intercepting endpoints from the mobile devices, but I have seen that it is possible for people to monitor internet traffic out of their cellphones and pick up endpoints to server requests. I have seen hacks on tinder where people can see response JSON and even automate swipes by sending http requests to tinder's endpoints.
My real concern is that people will be able to update/read/modify data on my backend. I can implement OAuth2 into my schema as well but I still see cases in which people could abuse the system.
My main question is whether or not using HTTPS is secure enough to protect my data, or if a session authentication system is needed like OAuth2.
Thanks.
HTTPS, providing it is properly configured, will ensure the message was not read or changed en route and that the client can know the server it is talking to is not a fake.
It will secure the transport. It will not secure the application.
For example supposing you have an app that allows you to send a message saying https://www.example.com/transfermoney?from=Kyle&to=BazzaDP&amount=9999.99 and the server does just that based on those parameters. Then I could send that message myself - I've no need to intercept any app messages.
Normally the server needs authentication as well as HTTPS to, for example, verify only Kyle user can send above message and not anyone else. HTTPS normally only gives server authentication not client authentication (unless using two way certificate HTTPS).
So the question is, even if an attacker cannot read or alter any messages between app and server can they still cause harm? That is the measure of whether it is secure enough.
A SSL connection is only secure with the content you are sending.
SSL encrypts and ensures the authenticity of the whole connection, including the requested method and URL
So i would say just using the SSL encryption is save to transfer data between - i might consider OAuth2 for password etc.
But i would recommend to use GET for retrieval data and post for authorized data
You're building an armored tunnel between two open fields.
Assuming that you use current SSL protocols and settings, and valid certificates from trusted issuers, you can pretty much assume the network is OK.
However it's still entirely possible to compromise any or all of your transaction from the client. Security really depends on the device and how well it's configured and patched.
I am creating an application and native apps which shall access a bunch of RestFul Webservices. We are already using HTTPS to secure the API, but wanted to understand if we still need something like an API Key or OAuth Key to authenticate the data
Encryption and Authentication are two separate things. Encryption merely prevents outside parties from snooping the transmitted data. You need Authentication if you want to control who has access to which resources using the API.
I am developing Restful API layer my app. The app would be used in premises where HTTPS support is not available. We need to support both web apps and mobile apps. We are using Node/Expressjs at the server side. My two concerns are:
Is there a way we could setup secure authentication without HTTPS?
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
I think you are confusing authenticity and confidentiality. It's totally possible to create an API that securely validates the caller is who they say they are using a MAC; most often an HMAC. The assumption, though, is that you've securely established a shared secret—which you could do in person, but that's pretty inconvenient.
Amazon S3 is an example of an API that authenticates its requests without SSL/TLS. It does so by dictating a specific way in which the caller creates an HMAC based on the parts of the HTTP request. It then verifies that the requester is actually a person allowed to ask for that object. Amazon relies on SSL to initially establish your shared secret at registration time, but SSL is not needed to correctly perform an API call that can be securely authenticated as originating from an authorized individual—that can be plain old HTTP.
Now the downside to that approach is that all data passing in both directions is visible to anyone. While the authorization data sent will not allow an attacker to impersonate a valid user, the attacker can see anything that you transmit—thus the need for confidentiality in many cases.
One use case for publicly transmitted API responses with S3 includes websites whose code is hosted on one server, while its images and such are hosted in S3. Websites often use S3's Query String Authentication to allow browsers to request the images directly from S3 for a small window of time, while also ensuring that the website code is the only one that can authorize a browser to retrieve that image (and thus charge the owner for bandwidth).
Another example of an API authentication mechanism that allows the use of non-SSL requests is OAuth. It's obsolete 1.0 family used it exclusively (even if you used SSL), and OAuth 2.0 specification defines several access token types, including the OAuth2 HTTP MAC type whose main purpose is to simplify and improve HTTP authentication for services that are unwilling or unable to employ TLS for every request (though it does require SSL for initially establishing the secret). While the OAuth2 Bearer type requires SSL, and keeps things simpler (no normalization; the bane of all developers using all request signing APIs without well established & tested libraries).
To sum it up, if all you care about is securely establishing the authenticity of a request, that's possible. If you care about confidentiality during the transport of the response, you'll need some kind of transport security, and TLS is easier to get right in your app code (though other options may be feasible).
Is there a way we could setup secure authentication without HTTPS?
If you mean SSL, No. Whatever you send through your browser to the web server will be unencrypted, so third parties can listen. HTTPS is not authentication, its encyrption of the traffic between the client and server.
Is there a way we could reuse the same authentication layer on both web app (backbonejs) and native mobile app (iOS)?
Yes, as you say, it is layer, so it's interface will be independent from client, it will be HTTP and if the web-app is on same-origin with that layer, there will be no problem. (e.g. api.myapp.com accessed from myapp.com). Your native mobile can make HTTP requests, too.
In either case of SSL or not SSL, you can be secure if you use a private/public key scenario where you require the user to sign each request prior to sending. Once you receive the request, you then decrypt it with their private key (not sent over the wire) and match what was signed and what operation the user was requesting and make sure those two match. You base this on a timestamp of UTC and this also requires that all servers using this model be very accurate in their clock settings.
Amazon Web Services in particular uses this security method and it is secure enough to use without SSL although they do not recommend it.
I would seriously invest some small change to support SSL as it gives you more credibility in doing so. I personally would not think you to be a credible organization without one.