I'm writing an API where partners will ingest my content. There is no user data to speak of, and it's all-or-nothing access. I'd eventually like to be able to restrict some partners to certain elements of the site, but that's down the road.
Does a two-legged oAuth fit my needs well, or should I just provide an API key and a secret key to use in signing the requests? I feel like oAuth might be overkill.
Thanks!
This blog post is a little old, but has some good info.
http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/
It sounds like an API key would be your best bet for now...who knows, you may never need oAuth, but you could always migrate to it in the future.
Related
I'm building a single-page web application, fully based on RESTful API. I've seen several topics in that matter, but some things remain unclear for me.
I will need users to log in. Here are some of my ideas:
I can send e-mail and password to API and use basic auth. I'm not sure where should I keep password, should it be encrypted and if so: how?
Can I use built-in session system instead? Is it wrong to use cookies directly in the RESTful API? Why is it so popular to send credentials/keys to API itself instead of using cookies?
I thought about having one API key per user, return it in login action and keep it in localStorage. I guess it's not the greatest idea to have just one key per user?
Then, I came up with idea to have separate keys table and add random keys each time somebody logs in. On logout, the key would go away and no longer be valid. This is more secure than previous idea.
How is it solved in simple projects? I'd like to make it simple but not ridiculously inserure.
Please help.
The commonly approach is to use the header Authorization in REST. The state of the application must be on the client side with REST and shouldn'a be tied to a particularly client kind (browser with cookies)
I think that this link could be helpful:
Implementing authentication with tokens for RESTful applications : https://templth.wordpress.com/2015/01/05/implementing-authentication-with-tokens-for-restful-applications/
There is also à great question to à similar question here : https://softwareengineering.stackexchange.com/questions/141019/should-cookies-be-used-in-a-restful-api
Hope it helps,
Thierry
Hi I was looking at flask-login at handles the session login nicely, this work good for templating and views where I have access to the session.
Nevertheless I have been trying to know if there is a way I can send a user_token to authorized a call. I looked at the documentstion and is very vague regarding this. It said that I should
Implement get_auth_token in my User object.
Decorte a #user_loader function that can load the user token base.
I have though seen the following (please correct me If I am wrong)
Cookie base to store the auth token is there a way I can decide to send the token as part of the parameters, body or in the headers insteado having to get it from the cookie.
I am not quite sure how to authenticate a call with auth token.
I got a Way better approach that fits better my needs. Basically I extends LoginManager pretty easy and straighfoward if you take a look at the source of flask-plugin you come to realize that there is a call that is made #before_request there is a method called reload_user, this is the what I end up doing
class CustomLoginManager(LoginManager):
def reload_user(self):
if request.headers.has_key('Authorization'):
ctx = _request_ctx_stack.top
ctx.user = User.get(token=request.headers['Authorization'])
return
super(CustomLoginManager,self).reload_user()
If in my header I pass an authorization key then I will try to load using this key instead of session based approach, of course I am going to need to add more security layer to this approach proably by signing the key but overall this was what I needed.
Thanks all.
BTW you can override a bunch of others method and I highly recomend to take a look at the plugin source, so you can understand more deeply what it does 644 lines of codes worth reading
https://github.com/maxcountryman/flask-login/blob/master/flask_login.py
It seems like you're wanting something like OAuth instead of using Flask-Login. In case you don't know (quoted from Wikipedia), OAuth is a protocol that utilizes tokens in order to access resources on behalf of a resource owner. Think giving a user the ability to give out a valet key to certain portions of your site. Many sites, such as Google, Facebook, and Twitter use OAuth for authenticating third party clients in order to access certain user resources.
Right now, there's a split between the less flexible and less complex OAuth 1.0a and the more flexible but more complex OAuth 2.0. Many libraries exist for OAuth 1.0a in Python, but fewer for OAuth 2.0. However, there is a selection of those for OAuth 2.0 if stability isn't a top concern right now.
For the client, Flask-OAuth is available if you're going with OAuth 1.0a, and it is maintained by Armin, the Flask creator itself, so you can feel assured that it won't die. For the provider, there's an extension called Flask-OAuthProvider with OAuth 1.0a support. If you don't mind integrating it yourself and want 2.0 support, pyoauth2 provides you with both a client and a provider, though it looks less maintained.
Hopefully this helps you with exploring one possible avenue to utilize auth tokens, albeit without using Flask-Login. In my opinion, one shouldn't re-implement a protocol unless they understand it, so I recommend reading up about OAuth even if you decide not to use it. Many great articles exist on it, such as this article from Google and this one, too.
Just as an update, Flask-Login now has a 'header_loader' function, which can be used in conjunction with the standard 'user_loader'. Taken directly from the docs:
#login_manager.header_loader
def load_user_from_header(header_val):
if header_val.startswith('Basic '):
header_val = header_val.replace('Basic ', '', 1)
try:
header_val = base64.b64decode(header_val)
except TypeError:
pass
return User.query.filter_by(api_key=header_val).first()
Here's the link to the section in the Flask-Login docs
Call me a newbie, call me dumb, rate down this topic. Do as you like, I'm just here to ask a question and hopefully learn something from it.
So I've been making an API for my website today (well attempting to) and I've noticed this "thing" on most popular sites API's such as Twitter, Foursquare, Tumblr called "OAuth". From my research today I have gathered that it's basically a way of giving the consumer a token to access restricted data from the provider depending on what the user chose without the user handing over their password and username.
But why do I have to use OAuth, why can't I just give out an API to the consumer key and they just use that? I will then see if the user has allowed access for the application, and they will have to grant access for the app to take information from their account, such as photos.
Something that also confused me is why the Tumblr API uses both. It seams on reading blog details they use a simple api key but posting on blogs you need an OAuth Signature.
OAuth is a protocol and has a set of specification defined by some expert group to define how to share data.
Basically what you are seeing is just a part of the OAuth mechanism,and there is a lot of communication and hand shaking mechanism to ensure the security of user data as well avoiding unauthorized access to data.
OAuth mechanism exits at 2 levels
three-legged authentication
Two-legged authentication
Both have their positives and negatives and there are a set of procedure which needs to be taken care for security and data integrity.
Allowing access only based on access_token/consumer key is really a very weak security mechanism and can easily be hacked by any one who happens to get access to your consumer key while OAuth system make sure by sharing a time bound access_token.
For details refer to this thread oauth-2-0-benefits-and-use-cases-why
Background: I am trying to create an SMS API service. The developers have a Dev ID, and an API secret key assigned to their developer account. The developers will be creating apps which will issue calls to my API. But the application issuing the call must be verified first.
Issue: The main issue i have is with authentication. I read up on OAuth and pretty much uderstood it. I read through this presentation (Slide 71-82). All OAuth articles talk about the OAuth 'dance' or the 'love triangle'. My problem seems to be, that i dont see a proper triangle in my case. Or, a better way to put it would be, the triangle doesn't seem to be complete.
What i mean by that is, in the case of lets say, LinkedIn, trying to make some app which helps users associate their LinkedIn acc with twitter, OAuth makes complete sense. Because LinkedIn needs to get resources from twitter ON THE USERS BEHALF (Cuz the user HAS A TWITTER ACCOUNT). In my case, only the consumer has a developer account registered with my service. The end-user doesn't have any credentials for the consumer to ask on behalf of. So how can i implement Oauth? So what will the consumer ask the provider? Will it only state that "watch out, here i come?". Cuz that seems pretty pointless unless its asking for a request token in exchange for an access token. But in this case since the end user doesnt even have an account, the steps seem useless.
So, i cant figure out how to go about this authentication issue. Ive tried thinking about using php sessions so it can help me associate a token with the particular client who is using the API. But the REST/OAUTH purists seem to disagree on the usage of sessions in authentication. They claim that OAuth is a standard which has proven itself and that is what I should use instead of coming up with my own obscure schemes.
From your description it seem that you're in a two party scenario only (developers write code which accesses your API on their own behalf, not on behalf of an end-user), so that means indeed that doing the full 3-legged oAuth scenario isn't needed.
You could use pretty much any authentication scheme and that would work (API Keys, other oAuth grant types [see below] or even ID/Secret combinations. In the oAuth world:
Look at the other oAuth 2.0 Grant types: especially resource owner PW grants - https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-26#section-4.3. It's slightly better than username-password because the PW isn't passed across the channel all the time (it passes once though) and it assumes the developer writing the code is the owner of the credentials.
Look at oAuth v1.0: this different in various ways to v2.0 but one feature it does have which some people like is the way tokens are used - which is rather than being passed across the wire they are used to generate a hash in the client and then the hash is verified on the server side. It's more expensive and complex than checking a key but it's less prone to attack.
In the non-oAuth world, if it's primarily a server resource used by developers directly, an ID/Secret or API-Key pattern is probably more than sufficient and it's much easier to implement for your developers.
Re: oAuth - if you're doing any type of user auth then definitely stick with the standard - the stuff is complex and having libraries out there really helps. If it's developer-api you likely don't need to go that far.
If you want the API to be secure in an ideal world anything which requires the security token to pass across the gaps should be secured using SSL, especially if that client code could be running on a mobile device or laptop which might communicate over wireless. If this isn't the case, someone could jump in an copy a token from one of the devs.
The only one of the protocols above that avoids this is the oAuth 1.0 variation since the secret never leaves the client but is used to hash instead. But it's complex. Last one to look at is the Amazon AWS pattern which does hashing similar to oAuth 1.0 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html and people emulate quite a bit.
I'm working on an API service for my website. I have read a lot on this topic, though can't decide which the best solution would be for me.
My API is simple. Each user gets an API key for each app that connects to my site.
There are only 2 different calls atm:
send_data
get_data
The get_data is quiet harmless, with send_data you can end new entries to your mini app. Possible security problems could occur there, though calls are limited. None of the data is useful if it would fall in the wrong hands. Server side I am protected for sql injection etc.
The calls are something like this:
http://example.com/api/?call=send_data&data=DATAXYZ&api_key=KEY
The pro:
It's super easy to use
The con:
It's not secure
I read a lot of similar questions here and elsewhere and OAuth pops up as a possible answer on almost all of them. I know OAuth, and i think it's a lot of overhead for something I want to be easy to use for my users.
As explained in this article It's not always needed to use authorization:
http://blog.apigee.com/detail/do_you_need_api_keys_api_identity_vs._authorization/
Is this all true for my case too though or would you still recommend authentication with or without OAuth?
Don't send the API key as a GET parameter: it would be logged at the very least in the browser's history (and probably also in the proxy, if there's one), which isn't very secure. POST it instead.
I don't think it would be unsecure, in fact the widely used Basic Access Authentication sends the username and the password as plain text (base64 encoded), and in fact when using a form to log into any web service you are sending the password as plain text too. Of course this works on the assumption that the communications between the client and server are secure, so you probably want to use HTTPS.
I'm personally using similar API authentication methods in multiple commercial projects.
So far I've never had an issue with security but I use a slightly different approach.
What I do different:
a) API calls use a user-id/login plus an API key.
b) the API key is a salted md5 hash of the users password (you can add the userid and something else as salt)
That means people are less likely trying to "guess" an API key, you can also more easily see who is using your API in your logs (without looking up the API key).
And users can change their API key by changing their password, so if they think the API credentials might have been leaked then they can just change it.
Regarding GET/POST : If your users do not use the API themself (for example by including it in own tools/scripts/code) then I'd use POST as serans suggested.
But POST has several drawbacks, it's not as "easy" to use. It just requires a bit more work to be implemented.
So I'd offer GET as well as POST and just add a note about possible security issues.