I have searched for this answer but haven't found anything and need help with the concept. So, we created an API with rails which feeds our Angular web app (separate server) and our iphone app. Currently people login through the form and devise from the api sends an auth_token for future interaction, the data is also secured using AWS keys.
Now we want to open up the API to the public, but only on certain subscription plans and maybe only part of the functionality. We want to use authentication similar to Pingdom were a user on the correct plan generates an api token within their account and sends this token with the request. This is where i'm at a bit of a loss, because if i secure the controllers of the API for some users who authenticate by token then this will effect the iphone and web app users too who don't have an api token?
I can not get my head around the concept of a private API which is available to some users if they have an api key. Please help.
It may help to think of your private and public APIs as not-necessarily-compatible versions of the same API. It's the same principle as introducing a v2 API that breaks backwards compatibility with v1, but needing to support both versions.
Obviously you wouldn't want your internal API to share a version numbering sequence with your external one. But there are various gems that will help you with handling versioned APIs, and that could include differences in authentication methods.
So the API that's available to your users could look, to them, like it's the only API available. It could have its own version numbering system, so that if you decide to introduce v2 of your public API you can. But the same system that maintains that API could do something similar for your "internal" API, ensuring that its endpoints are separate from the public ones, but allowing you to share common code between public and private implementations in the same way that a v1 and v2 API might share some code but would also have differences.
Related
I'm learning about developing APIs with rails, but I can't find how to secure the base methods like user creation. Let's say I have a rails backend API and a frontend mobile app. I want the app to be able to make API calls to create a new user. Off course, not everyone should be able to create a new user, so it should have some kind of authentication. I could use basic or digest authentication (doesn't really matter, because I'll definitely use SSL), but then I would have to hardcode the credentials into my app. If the credentials are discovered somehow, I would have to change them, but that would mean that all instances of the app are no longer authenticated and they can't create users anymore.
The things I would like to have:
Only my apps should be able to use the user creation calls.
It should be easy to change the credentials, or the credentials should change automatically over time. If they would involve the date and time for example, it would be harder to crack.
It should be impossible (or VERY hard) to beat the system behind it, while having knowledge of a couple of the credentials over time.
Would it be possible for example to let my apps generate public and private key pairs at random and use them? What's the standard way of securing these calls?
Thanks in advance,
Rugen Heidbuchel
I could share my own experience:
https protocol communication with API. That is your last sentence about private/public keys, all is built in into https.
Doorkeeper (we combine it with Devise) gem for Oauth (github accounts in my case) as authentication, while you can use pairs of user/passwords instead.
CanCanCan gem as authorization (User creation restriction is about authorization and not authentication)
Set of that three tools should provide essential security level for your API. I believe cancancan could be under discussion, while devise is mostly industry standard.
Apologies for the oddly worded title, however I could not come up with a better one.
My application should be able to perform a limited set of actions on an Enterprise Google Apps system. Users submit requests to the application, the application interprets these requests and then makes requests to Google resources as necessary.The point is that users, who normally do not have permissions to access/modify the google apps resources, will be able to use this application to do so in the limited ways that it allows.
My problem lies in the apparent fact that the OAuth2.0 authorization flow seems designed to allow third party client applications to authorize themselves as the user and access/modify the user's google resources, rather than a global administrator's. In other words, a normal API key type deal. Unfortunately it seems that Google's AdminSDK will only work with OAuth2 authorization.
Is there a way to use Google's AdminSDK API with OAuth2 (permanent access token, maybe? API key?) to do what I want? Or is there a different API I should be trying? The now-deprecated Provisioning API seemed to be able to do this.
I feel like there should be a way for the application to just pull something out of a secrets.json or secrets.yml, include that in the API authorization request and have Google servers recognize and grant access to the application without the user ever needing to see what's going on.
For the record I'm using Ruby on Rails, though I don't think that affects the question very much.
I need to develop an API to be the core of a web APP.
My initial idea was making a REST API that would treat all the request and then create some clients for web, mobile and desktop.
My question is, How should I manage the authentication for this situation?
I thought about using a token that would be passed with all requests to the REST API.
Im my case, I would not like to have something like OAuth because the ecosystem will not have multiple apps like Facebook/Twitter does.
NOTE: I must have the API separated from the client for web.
In more details, I would request POST /users/auth passing their password and username, and receive an auth token.
Is it a good approach or there is something better?
Agree that Devise is great for the auth in the application. For the API level, 3scale could help a lot (http://www.3scale.net) - it takes care of rate limits, keys, oauth secret distribution, analytics, developer portal and other stuff. There's a ruby plugin to get started here: https://github.com/3scale/3scale_ws_api_for_ruby.
Devise is a fantastic gem that handles authentication in rails apps. It also provides token based authentication. You can find many resources on the web (for example here) explainig how to use it. No doubt it will fit for your situation.
My question is not about FourSquare API and its functions, but about more simpler details that are not well explained on Foursquare API explanations. Thank you very much in advance if someone wants to help me with this doubts:
Foursquare API is a framework you can use to build applications for mobile devices, above of IOS and Android, so i can imagine that they have API for IOS (Objective-C) and Android (Java), right?
From API Doc: "Be sure to note that although API requests are against api.foursquare.com, OAuth token and authorization requests are against foursquare.com.". Does it mean that if i want to use FourSquare app, the users has to have an account on FourSquare?
From API Doc: "For example, if you write an iPhone application, every user who logs in with their foursquare account will be able to make up to 500 users/* requests and up to 500 venues/* requests, etc." I dont understand this sentence. Does it mean that for example, if you use an API method request like "checkins.add()", this method create two methods? one against api.foursquare.com to monitor the API limit requests, and another to your Web Application Server?
So as a question related to the third one, where do you have to store your database? is it stored on Foursquare cloud database because you are loggin there, or you have to create your own Web Service application with its own SQL database?
From API Doc: "All requests are simple GET or POST requests that return JSON or JSONP respones", so i can imagine that the Web Application Service should understand JSON. Well, my main question is, can i use Ruby on Rails to build the Web Application Service and Web Page frontend? I am seeing that there are some wrapps for RoR designed from third companies, but are not official and doesnt cover all the 2.0 API, just the ones they needed for their services.
If i want to create an app using FourSquare API, what do you advice me to use as a programming language/framework for the Web Service Application? the WSA that has to process the JSON requests and later store them on the database, interaction with users on the WebPage, etc.
i am so sorry if my questions are so simple, but i dont have any other place of this level of expertise.
thank you very very much in advance.
The API is REST/JSON based, which means that any language that can do an HTTP request and parse a string can be used. There are Java and iOS libraries available. But you could use just about anything - curl with bash would be a bit extreme but if that floats your boat...
For some of the APIs (search a venue, for example) you do not necessarily need a FourSquar OAuth user token. For others (like checkin) a FourSquare token is required. For any API calls that require a userid, your users will have to be FourSquare users and "trust" your application with their FourSquare data.
Only requests to FourSquare is counted. So if you do a single call to checkins.add() it counts as one call for the user that is doing the checkin. I wouldn't worry about the limits. As long as you're usage of the API is sensible they will not be a problem. And if they do become a problem and you're doing something extraordinarily cool, the folks at FourSquare might be sympathetic.
You have to create your own web server with your own database to store some information. The OAuth token is one. You probably want to cache venue information here for short periods as well.
Yes, your webapp will need to be able to understand JSON. Ruby has excellent JSON support - look for the json gem.
It is really difficult to suggest a language or framework without knowing what it is that you're trying to do. I wouldn't choose a framework based on the fact that you want to use FourSquare (anything will do) but rather on your experience and the unique features of your application. You mentioned RoR before - that would definitely work.
We are currently using an outdated screen scraper gem to import contacts from gmail/yahoo/etc. I want to update this to use the new OAuth based APIs so users don't have to enter their credentials on our site. I'm really intrigued by the work Plaxo is doing with Portable Contacts which Google also supports. It feels like that is a good direction for read-only access, and it is still backed by OAuth.
Are there any compelling reasons to just go with the standard OAuth API for these providers instead of going the Portable Contacts route? I'd like to know if there are strong reasons to avoid it. I'll still be using straight OAuth for the ones that don't support PC so it's not a question of development time, more one of support and confidence in the new approach.
The idea is that each OAuth implementation will be slightly different where as each Portable Contacts implementation will be the same. It's kind of like a REST API (OAuth) vs. a SOAP API (Portable Contacts --but with the same overhead as OAuth).
So you should theoretically be able to make one Portable Contacts Reader and hook it to any provider who supports it with no additional work.
In reality for now, you'll probably need to work with both Portable Contacts and OAuth-non-portable endpoints. (With most OAuth-non-portable providers hopefully moving towards Portable Contacts).
OAuth Core doesn't define either discovery (leading users to the OAuth URL which will let them authorize the resource to the consumer) or representation (informing the consumer about what authorization the token will provide). Without a spec such as Portable Contacts, these need to agreed upon ad-hoc by the consumer and provider (with discovery probably being simplified to a well-known URL). So Portable Contacts is just answering those questions once for each provider which uses them. You'll need to work out the ad-hoc answers if you want to support providers which don't, but you'll be using the same OAuth Core implementation for all of them anyway.
Portable Contacts itself builds on the OAuth Discovery spec, which seems to be expired without a replacement, unfortunately.