I really don't understand this OAuth authentication method, so I just gave up. The reason I decided to create my own was because I believe the functions my API will carry out aren't that big, it'll mostly be able to read data and occasionally write too.
Here's my plan for API requests on my site.
Consumer API Request with a special key > User Authorise's Application (if not done so already) > Callback URL to consumer upon authorising > Run API Script on provider > return result to consumer.
Is this okay? This is my first time writing an API for any site, so I'm here to learn.
In general, I would say that if you're trying to roll your own authentication protocol because you don't understand the existing ones, you're making a Fatal Mistake™.
The only time you should consider doing this is if you totally understand the protocol in question, and require some functionality from it that you are 100% sure it does not offer. OAuth is complicated because it has to be. Certain requirements exist to make sure it's secure.
In writing your own without understanding the complexity, you're setting yourself up to fail.
Related
I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.
Every application that generates dynamic content must have a server whose address is embedded inside the application to enable communication with server.
Now in the case of WhatsApp definitely they have also embed the server's address inside the WhatsApp application. For example someone reverse engineer the WhatsApp apk and found the address of the server, as well as he also found the parameters and all the stuff that the application sends to the server (i-e session, token, authentication key etc etc) for successful communication, so is that mean he can use these same parameters structure and the server address in different third party app to play/communicate with the WhatsApp server? Because server is just an electronic device that works on the digital signals and thats it. Server don't know that these parameters are coming from the authorized WhatsApp apk or from third party apk.
If yes, then don't you guys think that there should be solution to that problem?
If no, then what are the techniques and algorithms they are using to stop requests from unauthorized/fake apps.
I believe not any employee from WhatsApp will answer here to share the algorithm, but i know SOF is full of geeks, if someone knows how WhatsApp stops these kind of issues please share, otherwise i will be still glad to know about the advice and ideas that you guys have in your mind for the best security practices.
How banking, paypal etc and messaging apps including WhatsApp works in that scenario and how they stop the issue that i described above?
Important:
I am not going to reverse engineer the WhatsApp, i am just creating a server and fighting with this issue to be solved to secure my server and only accept request from my app but stop requests from unauthorized/fake apps.
Thanks & respect to all in advance who will contribute.
There is no way to prevent malicious reverse-engineering, resulting in a fake app pretending to be the real thing. While you are working on your server, you need to do defensive programming, that is, your server shouldn't assume that the request was sent via the app. So, if you protect your server against all kinds of malicious and deliberate misuses, then your server is safe.
However, that's easier said than done, because your project is developed by a finite amount of people and - if it becomes successful then - the audience contains a swarm of smart bad people.
You will therefore need to detect a subset of features that you need to absolutely protect against misuses and prioritize testing and improving those, by thinking with the mind of a fictional hacker, who would like to either gain unearned profits or do harm to your project. Schizophrenic, I know, but you need to do that on the server. You also need to improve the security of less than critical features, but at a lower priority and log the requests you get, so if SHTF, then you will have at least a chance to deduce what caused it and how.
If the phone app is in your hands as well, then you might implement some additional authentication for each version, like generating a version token for each user that downloads your app. Since the version token generator algorithm would not be in the hands of hackers, they would have to solve that on a per user basis, which is extremely laborius to solve this for several users if done by hand and if they work it out in a way to make it automatic, their solution would be viable only for a version.
So, there is no 100% accuracy in this area, but you can make life very hard and miserable for people payed to hack through your application.
I've created an api using .net core 2 and C#. I'm wondering if there's anyway to find out information about the computer or user that called the api. This is an internally used api so ideally I'd get the Windows user of where the api call came from, but if there's anything I can find out (like an IP address) I'd like to know how. If this isn't possible at all, I'd like to know so I can stop looking for a solution.
No, it's not possible. The server knows only what the client chooses to tell it, typically via request headers. However, the client can also lie, or "spoof" these headers. So, while something like User-Agent may look like it might give you some info about at least the OS/browser, all of that could be completely fabricated.
Matters are even worse with an API, as clients are typically thin, and the actual programmer or whatever connecting to your API must make a conscious decision to provide you with some particular bit of information, which most won't. A web browser typically sends certain standard things without user intervention, but even then users can change or alter what is sent.
After significant voodoo, I have finally got the scores API working. Turns out you have to set Enhanced Auth Dialog to disabled or Facebook ignores your publish_actions permission. Just a heads up in case anyone else is struggling.
However, I'm working entirely in the Javascript API. No server-side scripting is available.
The only way to publish a score is with an app access token. The only way to get one of them is to use the app secret, and that would have to be in the javascript code for the world to see. How bad is that exactly?
TBH I don't care if someone spoofs the scores to my little pong-style games. Good for them, only them and their friends can see it. It's just a bit of fun. But what exactly can go wrong if my app secret is published? Can someone hijack the entire application? Or is it just bad practice and nothing much can go wrong with a little mini game?
It's all purely javascript SDK so it seems to work only by user access tokens, so my first instinct is it's OK. But I thought I'd ask....!
What other permissions are you using? If you're using "publish_stream" I'm sure you could imagine the shenanigans that could ensue! Even worse, if the user has both your public and private key (which they will) they could create an entire spoof application that identifies itself as you!
The "domain" options in facebook should prevent this, but if there's any chance an attacker could do an XSS attack they could potentially write malicious apps that masquerade as your game.
Have you considered writing something very simple with google app engine for the sole purpose of dealing with the app authentication token?
I've been looking around at various APIs, and since twitter seems to be a common discussion point, I'll use it as an example.
A lot of APIs are implementing oAuth which is great for allowing the service to authenicate and authorize the application connecting to it, however, from what I have seen there doesnt seem to be a way for the application to verify that Twitter is actually Twitter (and not a man in the middle based attack)? I would expect to see some kind of signature (using a shared / public key) of the response body which I can use to validate that twitter signed it.
Is it just because currently there isnt really a point to a man in the middle attack with twitter tweets since currently, whats the worst that can happen (and why would someone want to give me invalid tweets)
On this point, if you were to sign the response, what method would you use? Im currently considering a HMAC-SHA1 signature of the response body using a shared key.
This is what the 'trust' part of SSL does.
-- Edit
I note this has been downvoted, but it's important that other readers realise it's due to a personal disagreement, not due to incorrectness.
In the .NET world we use WCF, which has many different security models, including signing (and if desired encrypting) each message/response. This adds up to a non-trivial amount of overhead, but can give you more 'trust' in the security model. You can switch to using binary-serialized data to cut down on the bloat and message size if you desire.
I'm not sure what other Web Service APIs offer in that area, though I'm sure someone else can add further details as needed.