I'm sorry if this is a daft question.
I'm developing an application that uses oauth2 to integrate with a 3rd party api via a server-side flow in node.
The one thing I'd like to confirm is that when I make the final post request to the 3rd party api to retrieve the access token using the node https module is whether or not the connection is encrypted.
From what I gather, when an https request is made from a browser, the browser handles encrypting the data on the client side. Does node encrypt the data in a similar way, or is this something that I need to implement myself?
If there is some background info that I've somehow overlooked in this regard, please let me know.
Thanks
To answer your question: if the OAuth API service you're querying is served over HTTPS, then your HTTP library (most likely request) is already handling encryption transparently for you. Any time you make a request to an HTTPS endpoint, your request WILL FAIL if the client is not handling encryption properly.
Related
Simple question. I would like to know when request headers are sent. Before or after an HTTP to HTTPS redirect? My security concern is our 3rd party vendors contacting our API with a auth-token request header if they carelessly make requests with HTTP.
Thanks for your expertise in this matter.
You cannot prevent that the your 3rd party vendors are sending a token over HTTP. Well, you should change the way you use the token. It shouldn't be necessary to even send it, encrypted or not.
Use the token as a pre-shared-secret. Then the authentication works as follows:
3rd party vendor sends request to server, provides username or something else which identifies him to the server
The server sends a challenge. This is usually the application of a one-way function - a hash-function. So, the server asks the client to send a SHA1-Hash of auth-token.
The client solves the challenge by calculating the SHA1-Hash of auth-token. Then he sends the result back to the server.
The server checks the result by calculating the same SHA1-Hash of the auth-token.
Supposing that you're using a secure hash-function an attacker has no chance of stealing the token as it is only transmitted as a hash-value.
Further reading:
https://blog.restcase.com/restful-api-authentication-basics/
I'm currently developing an Angular 6 page where we are doing some Http Post calls and sending the authentication as the header. The header is static (fixed password).
Is there any security differences sending it from the Angular frontend side with HttpClient, or sending it to an endpoint in our Node.Js backend (on cloud premises) and sending it there? Our thinking is that the "header" will be "hidden" for the client since we are sending it through our backend instead.
Another note, we will have the entire site behind authentication, and the clients logged obviously have the right to see the authentication, but we would like preferably not to.
Any thoughts and suggestions?
Depending on what you are trying to do with your post request, In previous projects I have worked on we have used your second approach and used a backend to validate requests before sending them on as I also have worked with secure systems and as a rule of thumb don't trust the client.
Here is some information from Angular's website on security with HttpClient https://angular.io/guide/http#security-xsrf-protection
I hope it helps.
I am building an angular2-login-seed that uses Passport.js with OAuth strategies for authentication. Obviously the default method of authentication with these tools is use of an HTTP cookie signed by express. Passport, from what I can tell, manages the actual Set Cookie header so that express can authenticate each subsequent request via request.isAuthenticated() and access the data set by passport via req.session.passport.dataHere.
I want to incorporate realtime data in the application via websockets. This of course means a socket stream coming from the server to the client. This communication is entirely separate from a regular HTTP server request meaning:
It does not contain the HTTP cookie that all HTTP requests contain
Express does not broker the interaction with sockets, it is managed with whatever implementation is used in the backend (sock.js, socket.io)
This makes it difficult to streamline authentication between HTTP requests to express, and websocket data to the backend as they are separate methods of communication.
From my research, this leaves me with two options. One of which is to use a library to give my socket implementation (preferably sock.js over socket.io but I need to do more research) access to the express session. Then I could authenticate the socket connection however I want. Issue is I have no idea how I would get the express cookie into the stream from the front since javascript cannot access it (HTTP only cookie).
Another common solution I've seen people jump to is to use JWTs (JSON Web Tokens). Implementations revolving around this store the JWT in localstorage on the front end. This is so the SPA (in my case Angular2 services) could send it with every request for 'stateless' server authentication AND we could send it via a websocket to authenticate the websocket connection as well (the front end JS has access to localstorage obviously). A couple things that come to mind when thinking about this implementation:
Is it even possible to have Passport OAuth strategies use JWT instead of the regular session information? What modification would this entail? From what I can tell the Passport strategies use some form of OAuth1 or OAuth2 parent strategies for authentication which defaults to using cookies.
Would storing this vital information in localstorage open the application up to security breaches (XSS, CSRF, etc)
If so, the most common workaround I've seen is to store the JWT in a cookie so it cannot be as easily accessed, spoofed, or forged. However this puts me back in the position I was in before using JWT, so might as well not bother.
Does this mean I'd have to use some sort of state management store in the backend (Redis for example) to manage the authentication and decoding of the JWT body? (I know nothing about Redis, etc).
The idea of connecting authentication between server HTTP requests and socket data is odd but seemingly vital to properly authenticating a socket connection. I'm a little surprised an easier method does not exist. I've done some research and have seen things such as socketio-jwt, express-jwt, etc however I don't know if this would be a manageable transition with my Passport strategies, or if it would be easier opening up express session data to the socket implementation, or if I'm going about it all wrong!
Any help or guidance would be much appreciated thanks.
Then I could authenticate the socket connection however I want. Issue is I have no idea how I would get the express cookie into the stream from the front since javascript cannot access it (HTTP only cookie).
With express-socket.io-session the session auth is done on handshake, and the handshake is a http request, so even if your cookies are http-only it will work. (Tested by myself)
Suppose I have an client/server application working over HTTP. The server provides a RESTy API and client calls the server over HTTP using regular HTTP GET requests.
The server requires no authentication. Anyone on the Internet can send a GET HTTP request to my server. It's Ok. I just wonder how I can distinguish between the requests from my client and other requests from the Internet.
Suppose my client sent a request X. A user recorded this request (including the agent, headers, cookies, etc.) and send it again with wget for example. I would like to distinguish between these two requests in the server-side.
There is no exact solution rather then authentication. On the other hand, you do not need to implement username & password authentication for this basic requirement. You could simply identify a random string for your "client" and send it to api over custom http header variable like ;
GET /api/ HTTP/1.1
Host: www.backend.com
My-Custom-Token-Dude: a717sfa618e89a7a7d17dgasad
...
You could distinguish the requests by this custom header variable and it's values existence and validity. But I'm saying "Security through obscurity" is not a solution.
You cannot know for sure if it is your application or not. Anything in the request can be made up.
But, you can make sure that nobody is using your application inadvertently. For example somebody may create a javascript application and point to your REST API. The browser sends the Origin header (draft) indicating in which application was the request generated. You can use this header to filter calls from applications that are not yours.
However, that somebody may use his own web server as proxy to your application, allowing him then to craft HTTP requests with more detail. In this case, at some point you would be able of pin point his IP address and block it.
But the best solution would be to put some degree of authorization. For example, the UI part can ask for authentication via login/password, or just a captcha to ensure the caller is a person, then generate a token and associate that token with the use session. From that point the calls to the API have to provide such token, otherwise you must reject them.
I'm writing an API that will be hosted without SSL support and I need a way to authenticate the requests. Each client would have a different ID, but if requests were authorised with that, anyone with a packet sniffer could forge requests. Is it possible to make a secure system WITHOUT relying on SSL?
(Some thoughts I had included OAuth, could that be implemented?)
Many thanks
Have each client cryptographically sign its requests with a client-specific key. Verify the signature on the server.
Using cryptography pretty simple. The main challenge is setting up the clients' keys. It'll be hard to do that securely without using SSL. There's no information in the question about how you set up client IDs, so I don't know if it's secure enough to set up keys at that point as well.
It's also going to be a problem if you serve the client code without SSL.
But hey, it's just an API you're building. Maybe the code that interacts with it is served over HTTPS. Or maybe the code is stored locally on the client.
I feel like a lot of people are going to complain about this answer though.