I would like to authenticate a specific application to make POST requests to a server. Imagine I have a game that can manage high scores via HTTP requests. It can retrieve them, but also create new ones on said server. Now, of course, I want to avoid that a user uses exactly this HTTP request to create a highscore, so I need to authenticate the application (the game).
One idea of mine would be to hard-code an authentication token into the game. This would then be sent with requests. But there I see the danger that this request will be intercepted by the user and the user will get the token with a program like Wireshark. Also, the application should be open source if possible, so I would like to avoid this option.
If you know of a way to authenticate a particular application without the user being able to read and use it, feel free to let me know.
Thank you in advance!
Related
I develop some internal applications for a client startup. All internal applications go through a reverse proxy, that verifies an OAuth login and lets the proxied webapp know of the user with a header value (X-Forwarded-User).
I would like to have users be logged in to the Meteor app when this header is sent, and to create the user if it does not exist.
Can't seem to find any good info on this use case online.
Where to start?
Would an ideal solution be to create a package for this (eg. accounts-from-headers)?
If so, would this be a common enough use case to make it public?
First of all, for the lack of words, I used "normal web page" on the title. Please let me explain that:
Recently, I have seen many websites such as shopify.com making the most out of the modern browsers support for html5 push-state and Ajax. Instead of submitting forms, requesting new pages I see them doing all that via their REST APIs. It seems to me like a very neat way to do things because it's faster (less page reload), and also allow greatly allows us to re-use the API code.
In these scenarios, the users access the service via the websites as they would normally do, however their interaction with the resources are powered by the REST APIs.
As I dive more into the documents, it seems like these API requests should be stateless yet should always have a mechanism to authorize/authenticate each request so I looked into OAuth2 for that purpose (Since I will need OAuth2 anyhow, to grant accesses to 3rd parties). Now, since in this particular circumstance the user's browser will act as the client to request the resources via REST, I want to know what is the recommended flow to do it.
Right now I plan to implement it as followed: (I'm using Symfony 2 with FOSRestBundle and FOSAuthServerBundle)
User should login via the web form as normal (Since we need to authenticate/authorize both for the normal web page as well as for the API Requests)
When the user logged in, immediately check if an OAuth client is already created for this user? If not then create it with GRANT_TYPE_IMPLICIT. If the client is already there, just retrieve it.
Proceed to normal OAuth authorize for Rest requests?
Edit 1:
Further research makes me think that I should not send back the refresh token to the JS app as this would be too dangerous if the browser is compromised. Perhaps I could store the refresh token for the user somewhere in the server backend once he/she is logged in, then can reserve a special link for the JS app to request for new access token when old one expires? This seems a bit messy to me tho.
I'm writing a web application (that is not to be published by Intuit on their App Center thing) to interact with QuickBooks Online (QBO) for syncing purposes, using VB.NET and ASP.NET. I'm having a hard time understanding how to do this exactly or where to start. What I understand this this:
User accesses your web application and the "Connect to QuickBooks" button (that Intuit requires for In-App authorization) is displayed.
Before the button is clicked you send a HTTP request to get OAuth request credentials using your consumer credentials.
Once the user clicks the button they get redirected to QuickBooks Online (QBO) where they can sign in and then authorize access to a certain company, giving you authorized request credentials.
QBO then redirects back to your site indicating you have authorized request credentials in which you send a HTTP request to get access credentials.
Once you have the access credentials you are basically free to interact with the QBO V3 API.
Using the access credentials you can then construct HTTP requests that send a particular HTTP method with XML/JSON in the body to perform a corresponding CRUD operation in QBO and QBO sends a response to indicate whether it was successful or not.
When your application is done interacting with QBO you simply make sure the access credentials are stored somewhere safe and let the user continue on with their life.
(Side Question: Is this correct or did I miss something or misunderstand something?)
My main question: Do you, as the app developer, even need to construct these HTTP requests or do you use their SDK or something completely different and I'm just not getting it?
I've tried to figure this out but it sounds like you're supposed to construct this all from scratch but then I look in their SDK and they have classes for all the different entity types but then their serializer doesn't serialize correctly and they talk about their DataService class and how you use that to send objects over and using some JavaScript files they host that I have only seen referenced but not explained by them, or anyone really, and information I do find seems to be outdated/deprecated and ya...
Maybe it's just that I'm new to web development and all this is way over my head right now, which very well could be.
(Off-topic-sorta: Is it me or is their site ridiculously broken? It just seems like a lot doesn't work correctly or things are just hard to navigate and find...)
Anyways, thanks for any help anyone can offer. If I need to give more details or ask a different question or something, just let me know. New to this and it's harder than I thought to ask things haha.
My main question: Do you, as the app developer, even need to construct
these HTTP requests or do you use their SDK or something completely
different and I'm just not getting it?
This is entirely up to you, the developer.
If you want to roll your own and construct your own HTTP requests, you certainly can. You almost certainly will still want to use a pre-packaged OAuth library, as OAuth is not trivial to implement.
However, you could also certainly use an existing code library/DevKit too, in which case the library/DevKit will construct the HTTP requests for you.
The DevKits should contain example code to show you how to actually do this stuff, so that might be your best place to start.
You are on right track.
First of all you need to register with IPP to get
ConsumerKey,ConsumerKey secret and Application ID.
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app/implement_oauth_in_your_app
if user don't have access token then 'connect to quickbooks' button shows up otherwise you can make it hidden.
request code : https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/QuickbooksAPI/DotNet/WebForms%20application/QuickBooksApiDotNetWebFormsSampleApp/OauthGrant.aspx.cs
access code : https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/QuickbooksAPI/DotNet/WebForms%20application/QuickBooksApiDotNetWebFormsSampleApp/OauthHandler.aspx.cs
After getting accesstoken, accesskey secret and realmID (companyid) save that to your database.
make sure to encrypt.
so next time same user connect to quickbooks they don't need to go through all of the above steps.
OAuthRequestValidator oauthValidator = new OAuthRequestValidator(accessToken, accessTokenSecret, consumerKey, consumerSecret);
ServiceContext context = new ServiceContext (appToken, companyID, IntuitServicesType.QBO, oauthValidator);
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits/0150_ipp_.net_devkit_3.0/0002_synchronous_calls/0001_data_service_apis
I have been puzzling over this and can't think of an good way of doing this. I am developing a website that would require the user to log in to use the system. I'm thinking of using ASP.NET MVC 4's built in authentication. That isn't much of a problem.
The user would be able to use tools on another server (our server would authenticate him and tell the other website, he is good to go, these messages are passed via HTTPS using XML). The other server, require us to create an authentication token for the user to use when the messages are passed between us.
We need to keep the token in our database to authenticate for every request/response with the other server. Which means that this "token table" knows nothing about the forms authentication time out on our server and vice-verse.
Now the problem, let's say the user uses the other server's tools. He would be on the other server for a long time, this would cause the authentication on our server to log him out, since there doesn't seem to be any perceived activity. The other server will not log him out since we are manually maintaining the token. This would be a troublesome for the user, because now, if he needs to use our service, he'll have to log in again even though he was "online" all the time.
Is there a way to "sync" the 2 authentications? At first I was thinking of getting our server to look up the "token table" (instead of using the built in authentication) so that if the last activity was x ago, the user will be required to log in again, this would solve the untimely logging out from our server. But I'm worried about the security implications.
What would be the best way to do this?
Thank you.
Desmond
If I've understood you correctly you are using Forms Authentication in an MVC4 application to authenticate users, but users will also use another web service located on a different server and so while they are using this other server you don't want the MVC4 application's authentication (for the user) to timeout. Is that correct?
If so, one idea that comes to mind is that your MVC4 application could have an API to the external world that would take in a username and use RenewTicketIfOld() to refresh the timer associated with the ticket. You could do this via the other web server making an HTTP request or by simply placing some AJAX on the page to call the API on every page.
There are, of course, security concerns with this method that you would need to consider. Without knowing more about your situation I'm not sure what solution would be best.
I have a flex application which collects data entered by the user and posts it off to a web service I have running on a back end server. The flex application does not authenticate users (it's available for anyone to use without setting up an account) and communicates to the web service using HTTPS.
There is an XML firewall in place for preventing certain malformed requests, DoS attacks etc and the web service validates all data received from the client.
If I was to sign the content then I could use the XML firewall to verify the signature but I assume that any certificate type data I embed in the client could be extracted out of the flex app through some means of de-compilation.
My question is, is there any way of limiting calls to the web service to only those from my flex client? I understand that a user could input bad information but I'm really trying to prevent another client or 'bot'.
If I were to introduce having user accounts to take advantage of a session based solution then presumably I still face the same issue when I'm trying to set up the account in the first place (would have to still be done in the flex app)?
Like TheBrain mentioned, the crossdomain.xml file is where you need to start, but this only keeps other flash based applications away. His idea about the random id is also a good one but I could see that being rather complicated to implement. You could implement user accounts only having those accounts set up through some other means than the flex application (something presumably more secure).
Another way would be to have a shared password between the application and the webservice side, and encrypt that password on both sides using some sort of salt that both sides could know. My first instinct is to think of a time based salt. You could pass the timestamp from the flex application along with the rest of the request and then take your password and the same timestamp concatenated together in someway, hash it and pass that along as well. In the webservice when you get the request, you take the same password (not passed with the request in the clear) and the timestamp that was passed and hash it using the same algorithm. Then compare. If they match then it is an authenticated request. You could even store a dictionary of passwords, and use a different one for each day of the week or something like that. Just however you do it, make sure that your two methods of determining the hashed password is identical. This should provide enough security for most applications. Let me know if any of this needs clarification or if I have misunderstood the question.
After re-reading your question, I see you are worried about decompilation. I don't have an answer for this off the top of my head. You could potentially store the password outside of the application and read it in, but that doesn't solve the problem of the person decompiling to be able to read that file. I will think some more on this and see if I can come up with something to guard against that.
you can add a crossdomain.xml to your server so then only your flex app can access your domain service and...you can generate some random id when you show the webpage and give it to the flex app as a parameter. so when the flex app makes the first service call, the id should be there. with the service response, generate another id and send it back to the flex to use it with the future call and so on.