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
Related
You get the problem reading the title. Is there anyway I can sign up customers using commercejs. The documentation is only showing login/logout methods but not sign up.Is there anyway I can do it through commercjs. Or should I use other authentication service like Firebase Auth??
There is no specific way to register a user as Commercejs does not store any kind of password.
The only way for registering a user is to use https://commercejs.com/docs/api/#create-customer as per API reference docs. however if you want to integrate some kind of custom auth you should definitely use this reference:
https://commercejs.com/docs/api/#issue-jwt-for-customer
This allows you to issue a JSON web token for a customer directly using your secret Chec API key. This may be a desirable option if you are integrating your own customer authentication, and simply need a token to authorize API requests as your customer with.
I have personally used this method along with Firebase auth.
I'm currently trying to add google sign-in support to our educational website. The majority of time users will just sign in with Google, but occasionally teachers need to be able to import pupil rosters from Google Classroom too. I've got all of this working using the guides from the Classroom developers site (https://developers.google.com/classroom/quickstart/js). I'm using https://apis.google.com/js/api.js to sign users in (gapi.auth2.getAuthInstance().signIn) with just the "profile" scope and then granting the extra classroom scopes if teachers need them.
I'm just reading the Migrating to Google Sign-In guide (https://developers.google.com/identity/gsi/web/guides/migration) and trying to work out if it applies to us or not. It's explicitly saying not to use gapi.auth2/gapi.client etc anymore and to use the new Identity Services Library instead, but there's no explanation how to use that to make API calls to Classroom (or any other Google API). The OAuth 2.0 JS guide (https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow) is still saying to use gapi.auth2 etc too.
So should I be using the new library to sign users in, instead of api.js?
And if so, am I still supposed to be using gapi.auth2 to make API calls, or should I be using the new library instead somehow?
Authentication for sign-in, and authorization for data access are being separated. Use the new Identity Services library for sign-in instead of api.js and the profile scope. This should be the case for the majority of your users based upon what you've shared.
Later, and as needed, continue using gapi.auth2 to obtain an access token and call the Classroom or other Google APIs.
Functionally, what this will look like is separating out your sign-in flow using HTML or JavaScript from gapi.auth2 and access/refresh tokens. Token requests for calling APIs (using either implicit or auth code) would be made only at the point they're needed. Say you'll use 3 different scopes at some point, each would be requested only when necessary, also known as incremental authorization.
I have created an app and some REST API on Google Appengine and deployed it to
www.my-appspot-id.appspot.com
I'm using Google Datastore to store my data and have created API's to access that data.
However, i can access my API directly also using
www.my-appspot-id.appspot.com/_ah/api/explorer
which means anyone can access them and can manipulate the data which i don't want.
How to restrict access so that nobody but some particular registered set of users can only use it?
I stumbled upon this tutorial recently, might be of some help.
I think you need to authenticate your endpoints and authorize only some client id.
OAuth 2 authentication : https://developers.google.com/appengine/docs/python/endpoints/getstarted/backend/auth
Allowed client ids and audience : https://developers.google.com/appengine/docs/python/endpoints/create_api#allowed_client_ids_and_audiences
To answer your question : you can't.
Google Cloud Endpoints is based on the explorer api: everybody will be able to navigate into your API, and see the differents methods available.
BUT if you add an authentication to your methods, the visitor will not be able to execute them.
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.