I have been looking for a way to protect my RESTful APIs. This appeared simple, but it seems to not be so simple. First off, I am writing an iOS app connecting to a Play Framework server. None of this has anything to do with Google, Facebook, Twitter, or LinkedIn (shocking I know). Oh, and my current plans do not require custom apps to use my APIs, its just my apps for the time being.
Basic Authentication
What appeared to be simple was a basic user/pass on a /auth method managing a cookie session. That may draw some groans as being too simple or weak but mostly it moved identity to a session key quickly verified. My initial setup was to expire the sessions every day, but that lead to the iOS app forcing a login daily proving to be an annoyance.
OAuth
I posted a question on an iOS board and received a blunt direction towards OAuth. My research of OAuth began but holy sh*t is that complicated and there does not seem to be any server side examples... just plenty of people complaining about how frustrating it is. All the client examples show connecting to Google, Facebook, Twitter, and LinkedIn. Oh Joy!
After watching Eran Hammer's rant about OAuth1 and OAuth2, it seemed fruitless to continue and his OZ idea (which looks really clean) is only at the early stages in node.js.
Question
So, my question to the broad StackOverflow community is... what do you do for securing your REST APIs?
I'd suggest to consider approach used by biggest players i.e. Amazon Web Services or Windows Azure - HMAC. Although it isn't comfortable in implementation, as you can see it's trusted technique.
The general idea is to sign the request's parts (i.e. headers) in the iOS with secret key and try to recalculate it on the Play app to verify that request is authentic and not manipulated. If it won't fail, you can be (almost) sure, that was sent from somebody, who uses valid secret key.
Take a look into Windows' document to get the concept (I think that for common task, you can use the less number of elements used for signing).
There is also other interesting post (based on AWS authentication) which describes whole process even better.
Edit
Of course you should realize that authentication in iOS and securing API requests are different things, even if you'll expire your session every 15 minutes, you can't be sure that somebody won't overhear it and then will be able to send a fake request from the outside. Signing every request should minimize the risk.
On the other hand, if you'll prepare clear rules for signing the requests and will write short doc (which I recommend even for yourself), you can deliver it to the other developer and he'll be able to implement it in (almost) any platform supporting SHA256, so you will have API ready for using from 3-rd party apps - if you'll decide to publish it in the future.
Since Play Framework is in Java, you could use Apache Shiro
I haven't used it yet.. (I am planning to though) So I don't know if it's the best option.
Just do something simple, send the authorization code / password in a custom header over HTTPS .
So the only problem with the Basic Authentication approach was that the user has to login every day? Why not offer the user an option to save his username/password on the device? That way he can choose between security and convenience.
Related
I couldn't find information on how other people solve this, so maybe you can help me out.
What I have
Multiple Services with REST APIs, that are secured using OpenID Connect. Connections between the Services work fine.
Now I have multiple developers, who sometimes need to write and execute local scripts (Python, R, Bash etc.) for quick analysis and testing.
What I want
I want to enable the developers to use the services as easy as possible, but still respecting security concerns.
What I tried
I defined the script itself as a client. Therefore I created a public client in my OIDC product, which is called somewhat like 'developer-scripts'. Using a library which handles the oauth dance, I can then execute the script connecting as aforesaid client. First time, the browser pops up and requests the user to authenticate and therefore authorize the client to use the REST API on behalf of the user. After that, the tokens are cached and I can easily continue working on that script.
This simplified drawing tries to summarize, what I just described
That works perfectly fine and regarding security I'm glad that credentials are not saved on the local computers as it was before with e.g. Basic Authentication. Furthermore, I'm able to control the access to different services on a user level.
Other ideas, which didn't convince me:
every web service also has an public client which can then be used as a client by the scripts (so the scripts aren't defined as clients anymore)
token generation is done somewhere else and the developer just adds the generated access/refresh token to the script
My problem
What concerns me about my current solution is the definition of that client. In the described case it would be either a generic client used by all developers for all scripts, or a new client for every developer who want's to write a local script. The latter seems to be a lot of overhead, the former may be a security problem?
So finally I'm asking the question: Are there any known best practices for my described use case?
EDIT:
I found a small article by [Martin Fowler](https://martinfowler.com/articles/command-line-google.html), he is basically explaining, how he is receiving a token to use for a local script. But in his case, he's using it for one certain use case, and not as a general public client. So unfortunately it doesn't really contribute to my answer.
I'm posting a question which I posted here again as I think this is the right place to ask this question
I'm wondering why Facebook is not handling the cookie export between browsers and related security concerns.This will be worst when they are using the "remember me" option as the cookies will be persisted for many days in the machine and someone can easily steam those cookies if it is a shared computer.
I think even Google is also not doing it. I copied the CURL from google with the cookies and executed it in the command line and I was able to get the expected outputs(mails). These 2 are used as identity providers in most cases. So I believe the applications which are using these two as the identity provider and using the remember me option which is provided by them also should face a similar threat.
Is there is an identity provider which handles it properly, maybe with the device fingerprinting or any other technologies?
Appreciate if someone could mention such IDPs and how it is handling that use case.
I need to develop a chatbot with these properties:
Platform - Skype for Business On-Premise
Function - Replies to user queries by looking in various knowledgebases (Multiple Platforms - Databases, Web APIs, etc.)
Basic textual conversation to begin with and will gradually evolve to send attachments
No calls/videos, just chat
Will be hosted on an external server with organisation VPN
A simple sip will be created for the chatbot which can be pinged by any user. I should be able to get this through to our IT dept.
Limited time for development
Scalability is an essential requirement but the organisation is fairly new to this, so they might be patient and allow me to make mistakes
My research has led me to these possible approaches:
SfB SDK - I have rejected this approach because it requires the client to be running at all times and doesn't seem to be scalable
UCMA with Application Endpoint - Haven't rejected this approach, but seems like I'll not go ahead with this because creation of Application Platforms seems tedious and requires me to make a lot of SfB server related IT requests
UCMA with User Endpoint - Great affinity towards this. I have experimented Tom Morgan's (thoughtstuff.co.uk) stuff and this seems like something I can start off right away
UCWA with Application Endpoint - Rejected this approach, because UCWA (from my research) appears unsuitable for On-premise and the setup also seems time consuming
UCWA with User Endpoint - Haven't rejected this approach, but I'm not sure if the Web API way is really a good approach for On-premise platform
I'd like to ask how am I doing so far, but that seems too vague
What would you suggest is a good way to achieve this?
Also, can someone be patient enough to reply the drawbacks and advantages of each approach for my use case. I'd like to make an informed decision and not reject any approach, just because of a misunderstood overhead
I have been asking around in my organisation and other circles.
And since I am not receiving any quick responses, I'll keep adding what I have learnt.
This way a person in the dev community will have a log of how I went with this.
UCWA is better suited for S4B online (compared to on premise) and is generally used by people who are comfortable with RESTful and have low familiarity with .NET development
UCMA is apparently THE WAY to go and for any on-premise bot requirements, preferably with an application endpoint.
So for our development, we are starting with UCMA user endpoint so that we can deliver a basic start as a version-one
And meanwhile we shall also get in touch with the IT department and Lync administrators for creation of Application Endpoints
Once we have this the same functionality that we had with the user endpoint will be copied over to the Application Endpoint version
Keep watching this space for further updates
I am using OpenTokSDK for iPhone (using it Natively)
I have made the code for calling but just there is one problem.:-
I have to statically Add the SessionID. But i want to generate the ID Dynamically.
How can I do this ?
Please help!
Thanks In Advance
Full disclosure: I am a developer for TokBox.
The only safe way to get session ID and token credentials to the device is by developing an application server that suits the specific needs of your app. We have a number of server-side SDKs available on GitHub (link) that will interface with the OpenTok server API to generate this data.
Note well the server-side SDK is enough to get your credentials generated, but not all devices will be on the same session, so things like user management and application workflows are all considerations that cannot be easily written to an open source library.
That said, we did try to make some of these examples more clear by writing code examples on our blog (link). You can relieve much of the overhead of writing your own application server (no doubt a daunting task, especially the first time around) by leveraging one of the third party signaling services available, like Parse and Pusher, to name two.
Wobbals is correct, and In addition to what Wabbals has mentioned, generating sessions/tokens is very simple, the sample code required for each server language (PHP, NodeJS, C#, Ruby) is located in OpenTok's Github page.
Furthermore, if you choose not to have server side code and use Parse to handle your back-end, there is a wonderful writeup about how to use Parse's cloud code module for OpenTok to generate sessions and tokens.
Good Luck!
I strongly felt that the tokbox tutorial was quite basic but had steeper learning curve. So I ended up wrote out my own app-cum-tutorial.
Though late, I felt compelled to post here:
How To write your first iPhone Video Chat App using parse and opentok(tokbox)
I am currently writing the backend for a service which has 3 clients: browser, android native and iphone native. I am having a little trouble with coming up with an authentication system since I don't know what can really be done on the clients.
I am using django + twisted for the backend.
Basically, I am going to be writing RestfulAPIs to open up for the clients on both phones to call.
Now the real question is, how should I come up with an authentication system?
I have thought about using sessionids, this works very well with the browser and I can use django's integrated app for that.
However, I don't know if it's possible for both the iphone and android to obtain a unique sessionid on the handset. Should I write an API call to distribute unique sessionids?
if that's the case, is it possible for me to still use django's authentication system since a lot of the stuff here are customized? ( I am not even using a rdbms - I am sticking with mongodb, so I was on the verge of dropping django's authentication app ftm).
I have looked at foursquare's API and their basic auth method requires you to pass in user:password in every http request header. That adds 1 additional authentication each call which can kind of seem excessive.
Please provide any kind of advise that you could give.
You might look at digitally signed RESTful requests, such as what is done with Amazon S3.