Trying to get a handle on how these things work.
If I register an API key with Twitter, Foursquare, or Facebook, and I wanted to build an app on top of them. What are the general rules for API use?
Can I save/cache data a user allows me through oAuth to my own database, or am I only allowed to use it but not keep it?
I don't know about all APIs, and you should probably read the terms of service of each API you'll use.
Saving data you'll frequently need will decrease requests you'll have to do to each API, which they will be thankful for, so it shouldn't be any problem.
However, it is possibly that they require you to erase saved data if the users revoke access to your app, etc.
Related
I am creating a iOS native app that talks to a Flask API.
My plan is to have the iOS front-end handle log in with Auth0 lock. Afterwards, the front-end would store the JWT in local memory and use that on every API request.
On the back-end I plan to have a User table with both an internal ID field and a Auth0 ID field. Per API request I would look up the user via the Auth0 ID and then use a library like flask-bouncer to handle resource authorization.
Is this a valid approach?
Are there any out of box features of Auth0
that I am rebuilding? If so what are the advantages of using the
Auth0 version?
Are there any future implications that I am missing
with this approach?
What are the advantages of using Auth0 instead of building it myself following something like this?
Anything else to consider?
Is this a valid approach?
Depends on what you call valid. But it would work, yes.
Are there any out of box features of Auth0 that I am rebuilding? If so what are the advantages of using the Auth0 version?
You're not using authorization using scopes. See Auth0's tutorial for Flask.
Are there any future implications that I am missing with this approach?
That's a broad question that I wouldn't know an answer for.
What are the advantages of using Auth0 instead of building it myself following something like this?
You do not have to worry about signup, login, verifying emails, bruteforce protection, resetting passwords, MFA, etc. You get all of those things out of the box. But... some more complex things might require additional effort on your side.
Anything else to consider?
Make a clear decision on where you're storing what info and whether you want to store your users in your database at all. An easy pitfall is to have multiple sources of truth for certain data that's both in Auth0 and your database (e.g. first and last name). Also see the User Data Storage Best Practices.
We have a large high traffic site with a lot of data on it (similar to Kickstarter), and we want to provide to our content/project creators a means of pulling their data from our site via an API.
Someone suggested I use OAuth, however my experience with OAuth is limited to setting up a twitter datasource.
What I want to do
Provide a user an Application ID and a 'secret'
Allow this user to connect to our application via an api endpoint, authorizing themselves using the api ID and secret
Once verified, allow this user to pull only their data from the application
The data that a user can pull: votes they have cast, pledges they have made, purchases they have made, projects/ideas they have launched, data about those projects/ideas (votes/purchases/orders/cancellations etc)
My question is:
Is OAuth overkill?
Is there a better way to handle a user/users website to connect to our API and pull/verify certain data by using the API we make available, while requiring each incoming request to be authorized for the user/site initiating that request.
Ideally, we will have an endpoint that is accessed as:
https://api.oursite.com/request/params
We want this to be as simple as possible for our users that wish to implement this interface. Thanks for your help!
Generally it's OAuth, in combination with SSL. That's the standard and is likely to stay. Before we saw also logins: username + password to access an API but that's becoming less and less.
So the suggested way is OAuth. There are no serious other solutions yet. To make it easier to adopt your API you could release some classes in some development languages so developers can have a quick start. You could start releasing those classes at for example GitHub to raise adoption of your API and get a quick access to developers. They might, if you do well, even start improving it.
I would like to programmatically query the Flickr API using my own credentials only just to grab some data from there on a frequent basis. It appears that the Flickr API is favouring OAuth now.
My question is: how should I authenticate the API without user intervention just for myself? Is it possible any more?
Once you have received an oauth_token (Access Token), you can use it for multiple subsequent API calls. You should be able to persist the token in a data store (I haven't done this myself) and use it even after your application restarts. Of course, you still need to write the code to get the Access Token the first time.
If your application is already coded using the old authentication API, it looks like there is a one-time call that you can make to get a new-style Access Token. See http://www.flickr.com/services/api/auth.oauth.html#transition
Even if you don't have a coded application, you might be able to use the API Explorer for any of the calls that requires authentication (flickr.activity.userComments, for example) to harvest an api_sig and auth_token.
The scenario which you are describing is sometimes referred to as 2-legged OAuth. (https://developers.google.com/identity/protocols/OAuth2ServiceAccount)
Google APIs support this via a 'service account'.
Unfortunately Flickr doesn't seem to support this kind of interaction.
For public data interaction (like downloading your public photos (photostream) from your account), there's no need to authenticate. You can get the data using only the Flickr user-id.
For other interactions (like downloading private photos (camera roll) from your account), you'll need to follow the full OAuth procedure at least once.
Assuming I want to create an app that allows users to login. The accounts are stored securely in a server. Some pages are also not visible to users who haven't logged in yet. Can someone guide me on how to do so? So like how to deal with "sessions" and all that. How would I do that if the database online is MySQL?
On another note, to implement "OAuth" the database has to be OAuth-compatible, am I right on this? And if so, how would I use OAuth on iOS? Is there an Apple API for that?
I appreciate any help / guidance
Thank you,
Let's do this part by part:
It doesn't matter what is powering
the server-side of things. Be it
MySQL, Oracle, SQLite, if you have a
dynamic language that connects to
that DB and outputs XML or JSON
data, you're set.
Dealing with sessions is easy. You
can use NSHTTPCookieStorage to
have that handled automatically for
you. Because sessions are set via a
cookie, any HTTP request will set
that cookie locally and send it in
future requests.
As far as permissions go, I would do
that validation server-side. Because
you have the session, and you should
know server-side wether the user is
logged in or not, just send a list
of pages the user can see.
There are a few OAuth libraries you
can use. The OAuth project lists a
couple that seem straightforward
enough to use. If you're looking for
Twitter integration however, a
question has been asked here
with pretty good answers.
Returning to the server-side of
things, this can be easily achieved
using a dynamic language such as PHP
or using the Ruby on Rails
framework. RoR is really good in
that aspect in the sense that you
can quickly bring an API up by using
its gems (Devise, OAuth2,
etc)
I'd like to be able to give my users the ability to display their recent tweets on their profile on my website.
I have a PHP twitter wrapper and understand how to make API calls etc, but I'm just wondering how to manage the user information.
What is the best practice here? I want them to be able to enter their credentials once, but I would imagine storing everyones username/password myself isn't the best way to go about it.
Is there a way to make an authenticated call once, and have twitter remember it?
Should I store the usernames/passwords and then just make a call when displaying the tweets?
Any advice here would be great.
Thank you,
Use OAuth, no need to ask users for their passwords:
http://apiwiki.twitter.com/Authentication
I think everyone would/should probably agree that storing the twitter usernames/passwords is bad, I can't believe they ever created a situation where you needed it.
You should never store unencrypted credentials of any kind. If your solution involves holding onto a plaintext password, even for a brief time, you need to rework something.
Absolute best practice would be to hold no information yourself - use cookies or OAuth to handle your authentication. A session token or cookie can be disabled by the user at will, giving them control over the behavior of your site.
Next best thing (although still pretty undesirable) would be to hold non-reversibly encrypted credentials to resend to Twitter whenever you need to display tweets.
You don't need their passwords to pull their latest tweets, unless their profiles are locked, simply pull the feed from http://twitter.com/statuses/user_timeline/username.rss
You should look at Twitter's OAUTH support (although they have disabled it). This enables you to prompt the users once, and then store a response from twitter which will allow you to post
Tweets that you would want up on your web site are generally public anyway.
If you did need to authenticate somewhere (perhaps allow users to send new tweets) on a user's behalf, the best practice is to prompt the user at the time you initially authenticate and then store whatever authentication token is returned by the resource rather than the credentials used to get it.