I'm currently building an oAuth2 server so that external clients/devices can access data from my service without having to send over user credentials with every request. I've finally grasped how oAuth works after spending an entire day reading numerous tutorials and online documentation, however, there's still one thing that I'm rather unsure of...
When sending a request for an authorization code to an oAuth server, how should I deal with a callback to mobile devices and devices that aren't a webserver?
E.g. this request to my oAuth server will send an authorization code as a callback to a specified webserver (http://client-url.com in this case)
http://mydomainname/oauth2/?client_id=test&grant_type=authorization_code&client_details=test&redirect_uri=http://client-url.com&response_type=code
The server at http://client-url.com will receive a response containing an authorization code and the developer will be able to store a user's oAuth credentials accordingly.
Obviously a mobile device isn't a webserver, so is there a standardised way of dealing with this? I've read online that you can define something called a custom URI scheme within iOS and Android apps. But what about the other mobile platforms out there? And desktop apps? I want my API to be accessible from as many platforms and devices as possible.
The reason why I'm asking this question is because I want to add validation to my oAuth server so that users can only register apps with valid callback URL's. I wasn't sure if should allow any other type of input as a callback apart from a valid URL.
Can anyone shine any light on this? I want to avoid spending hours validating and testing this across all devices as I'm sure anyone that has developed for multiple mobile platforms in the past must have some knowledge about this.
Thanks in advance.
Related
My scenarios is simple and perhaps not only me deal with. I have an webservice that is used my a number of my mobile apps. I would like my webservice only be accessed from my mobile apps but I don't wish my apps's user be bothered with registering an account. How can I achieve that kinds of security?
I have read about API KEY and OTP, but it doesn't really convince me.
It isn't possible to do what you want 100%. The reason is that if the security is in your Mobile App, or travels over the internet, it is theoretically possible for someone to read your code or scan your traffic and then impersonate your Mobile App.
However, you can get good results with simple server side checks. EG, from your Mobile App, add a variable into HTTP calls which is checked by your backend. And, most importantly, use SSL. You can make this more complex as well, such as providing a token from the server and then requiring this token back on every call.
It's not unbreakable... but it will deter the casual hacker. And it will probably only take you 10 minutes to implement.
I have a Delphi application, that needs to send a generated PDF file by email to one recepient of a predefined list of recepients.
I do not want to mess around with MAPI (not all customers have configured this)
I do not want my customers to enter their mail account details (this means SMTP is no option either)
Therefore I consider to use / setup a PAAS web service to receive the email text, the pdf file and the index number of the recepient to actually do the work.
My question is: Does an out-of-the-box solution exist to do this in Delphi, or what would be a preferable way?
For instance I considered using Google App Engine but there seems to be no builtin support in Delphi. I would prefer an out of the box solution or a tested solution with decent documentation. The server part should be as simple as possible.
Edited: Some clarifications:
The resulting exe is installed at the customer computer. I think setting up an extra mail account therefore is no option, because someone could extract the credentials from the exe and abuse the mail account. The same seems to be true for web services that provide only one (login/password) access.
Using OAuth2 seems to be no option either because I do want to send the email without user interaction.
If credentials need to be saved in the executable, and the existing answers suggest so, they should at least provide only very limited rights.
Is this solveable at all?
Is this solveable at all?
No.
If you require that neither the user (by filling in a login form, as is the case with OAuth 2.0) nor the program (by providing hard-coded credentials) authenticates with the web service, the communication with the web service can not be secure.
I suggest to re-think the security requirements and make them much clearer in your question.
To send mail you can use a webservice like http://www.mailgun.com/ or http://aws.amazon.com/ses/
They provide you with a http(s)-api that you can use to send email messages.
You can use Google App Engine with some programming in Python, PHP, Go or Java:
define a HTTPS address where your GAE application listens for POST requests
POST the PDF and the Email text with TIdHTTP
receive the PDF amd theEmail text in the GAE HTTPS server and forward it to the recipient
Here is an excerpt of a Python example for Google App Engine which handles a POST request
class Guestbook(webapp2.RequestHandler):
def post(self):
self.response.write('<html><body>You wrote:<pre>')
self.response.write(cgi.escape(self.request.get('content')))
self.response.write('</pre></body></html>')
Regarding OAuth: GAE supports OAuth but it is not required.
We r finally taking a leap into writing a mobile application for some of our platforms core functionality.
After spending some time - narrowed down that it is a HTML 5 application, CSS and Apache Phone gap to support different platforms mainly IOS and Android
We are writing WCF based REST services and have a question about securing the web service calls - specially ones for new user creation and login.
How can we ensure that the web service call to create a new user account or subsequently to log into the app is genuinely originating from a mobile device and not via a brute attack or someone trying to execute a service if they do discover the URL? Is there some kind of device identifier that we can depend on as part of the request (or something we embed into the app) etc or are there other more reliable techniques.
Any help would be appreciated.
Regards
Sid
Good question: I use the device plugin to get the device uuid and then hash it with the user email and the timestamp of the registration to create a key. One way hashing is your friend in this scenario. Keep all of your communication on https secure socket layer and create keys based on the UUID and you should be able to solve this problem.
With very little experience designing mobile or web based systems, I really have no idea idea what sort of methods are generally used for exchanging information from an application on a phone with a web service on a server. In my scenario, the app is on Blackberry 10, and I think the web service will be run on Heroku.
I want to periodically exchange small amount of information between client apps and the server's web service. I have tried searching for how this might be done, but I have had no success in finding anything helpful. Any sort of information on how I can or should do this would be appreciated.
To clarify a little: I am particularly interested in how small amount of data are typically stored for transfer, and then what mechanisms are generally used for actually sending and receiving the information.
Typically, this is handled via HTTP calls through the mobile device's SDK. I have no idea what the objects are on blackberry, but the typical workflow looks like this:
Write a web service that does something (e.g. calculation, retrieve data, store data).
Publish web service to a web server. This web service has a URL. If you are following RESTful approaches to web services, there would be unique URLs for resources available through the web. Each function that the web service performs uses one of the common HTTP verbs, e.g. GET and POST. You use "GET" to retrieve data from the web via the URL. You use "POST" when you also want to send data to the web.
From the client SDK (e.g. iOS, Android, Windows Mobile, Blackberry), build an HTTP request through the standard objects that are components of the SDK. Sometimes there are open-source libraries that provide wrapper classes that make this process easier. This HTTP request should either just use the URL (in the event you want to make a GET request), or you should build the request via the "body" of the request with the data that you want to send to the server, in the event of a POST request.
Both types of requests typically produce a response from the server, which you then handle and parse using objects and events that are typically components of the SDK.
You then do whatever you want with the parsed response in the context of the client.
Although the specifics of the implementation of this pattern can vary, the pattern is pretty consistent across all the major platforms; it's really the only way to do it.
I have a SharePoint server running on my network and I am trying to build an app in Delphi which allows me to access the various SharePoint Web Services hosted there.
Running my app on the same network as the SharePoint server works fine, however, when I attempt to run it on a VM which is not part of the same Domain I can't get authenticated. I was looking for some advice as to how I should be handling authentication for this type of scenario, more specifically, should I be prompting the user for their credentials or is there some built in security model I can use for this?
Ideally I would like to try avoid dealing with Usernames & Passwords in my app and let the OS handle that sort of thing, however, at the moment I can't seem to see any other way around this.
After some investigation, for my particular scenario I decided that the best approach would be to use WinINet. I chose this approach over Indy because after some thorough investigation I found Indy did have some bugs & also it didn't have all the authentication handling we needed built in.
WinINet supports prompting for credentials & automatically authenticating across the wire. See Handling Authentication.