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.
Related
Is it possible to use Smartsheet's API to sign into Smartsheet on the Web. I am thinking of creating a form-based auth that uses the API to login. Has anyone done something like this? or is this even possible with the tokens that can be produced by the API. I am aiming for a web based single sign on without using SAML.
I'm not totally clear on what you are asking, so I'll address each question individually in hopes that it addresses your overall question:
Is it possible to use Smartsheet's API to sign into Smartsheet on the Web?
No, you cannot create a web session using the api. For 3rd party apps, that would defeat the purpose of using OAuth2 since the whole goal with OAuth is to grant limited access to protected resources. For user-generated access tokens, it could be feasible, since those tokens have unrestricted access, but the API does not currently support that.
I am thinking of creating a form-based auth that uses the API to login. Has anyone done something like this?
I assume you mean you will create a form to collect a user's Smartsheet credentials and use those to have an SSO experience into Smartsheet? This is technically possible, but I'd strongly discourage against it. To create an SSO experience, you'd need to retain the password in a way that allows you to POST it on behalf of the user. This means you'd store it in a 2-way encrypted state (at best), which is definitely not best practice. Again, I'd highly recommend NOT doing this.
I am aiming for a web based single sign on without using SAML.
If you want an SSO experience into Smartsheet, you can either use SAML or Google (not truly SSO, but pretty close). There isn't an API-based approach currently.
Side note, if you want to go the other way, meaning you have a website and you want to use Smartsheet (or any OAuth2-based API for that matter) as the identity provider, you could use the 3rd Party OAuth2 flow. See the docs here. You could then add a "Login with Smartsheet" button to initiate that flow, much like we see everywhere on the web with "Login with Google" or "Login with Facebook".
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 was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/
I want to use the Linkedin API to get details of jobs posted by any company. This data seems to be public, so do I need to integrate Oauth?
The LinkedIn API isn't designed for developers to grab information and present it to people who haven't authenticated (public display). Making calls as a single authenticated user to store it or present it elsewhere is against the Terms of Use for the API. Additionally, you can't store the data you get - it's just designed to present to the authenticated user.
If you want to use the API to present this information, your users need to authenticate with LinkedIn and then you can make the call on their behalf. This is probably easiest to do using the Javascript framework.
The data is not quite public. You need an API key and you need oAuth to make API calls. Probably you dont need it if you just want the public profiles. Read the docs (RTFM).
http://developer.linkedin.com/rest
http://developer.linkedin.com/documents/job-search-api
I'm trying to get access to the Google's todo feed with this url:
https://www.google.com/calendar/tdl?secid=<SECID>&tdl={%22action_list%22%3A[{%22action_type%22%3A%22get_all%22%2C%22action_id%22%3A%221%22%2C%22list_id%22%3A%2215052708471047222911%3A0%3A0%22%2C%22get_deleted%22%3Afalse}]%2C%22client_version%22%3A-1}
If I open this in my browser with a correct secid, it shows me right what I want.
Now, the question is: how do I get secid programmatically (specifically, in a java program)? I have access to the authToken (from CalendarService), but I have no clue how to use it to authorize my access to the URL above.
I tried to use the url http://google.com/accounts/ServiceLogin, but I didn't find any examples.
Any help, please?
From what I read secid is a session ID obtained from browser's cookies. Whereas your case uses Java which implies a server app. If that is the case, you want to drop the idea of using secid entirely.
Instead, you want to check out Google's OAuth2 documentation. If you are using Java, most likely you would be interested in the web-server OAuth flow. Pay special attention to the sequence diagrams.
The key steps include:
1) Obtain an authorization code from Google OAuth with the user's consent. For that, you redirect the user to Google with the appropriate scope. Check the list of calendar scopes for your case. Once the user consents, Google redirects back to you with an authorization code.
2) Call Google OAuth with the authorization code and your app's credentials to exchange for an access token.
3) Call Google's Calendar API using the access token.
And if you use Google's Java client as suggested by #ChaosPredictor, chances are some of the steps are already wrapped into the Java client (and your code will be much simpler).