Passing multiple sessions_key to Facebook API - api

I'm current developing web-app that allows a user to associate their account with their Facebook account.
I have no trouble getting the users Facebook id/session_key and extended permissions.
What I am having trouble is caching the users data in a single call.
Their documentation for User.getInfo allows multiple uid's to be passed to the API and the basic info returned but I need additional details but it doesn't state mulltiple sessions_keys are allowed.
Is there an alternative or will I just have to take the multiple web request hit?

I tried to use the Batch.run for Facebook but it turns out you cannot pass commands that require different sessions keys.
So I have to take the multiple hits.

Related

Has anyone set up an API for a group of users in BeyondTrust,

Has anyone set up an API for a group of users in BeyondTrust, and if so, will the members of the group be able to see and access each others passwords or do I need to create separate API Keys per each user?
I have not tried this as of yet, I do not fully understand the results of attempting an API for a group of users with in BeyondTrust Password Management systems, and I am afraid if I set up an API for a group of users, they will be able to view and utilize passwords that do not belong to them.
Is an API for a group even a thing, or do I have to set up API keys per user?
Password Safe users can use the API to do most of the functions available through the UI. They operate under the same security model regardless of access method, with the caveat that accounts need to be indicated as accessible via the API. This means that you might not be able access every account that you have access to through the UI, via the API but, it does mean you cannot access any account through the API that you don't have access to through the UI.

Microsoft Graph and Partner Center in the same api gran

I am looking to create a login that verifies a user account via the graph api and also verifies they are a microsoft partner via the partner api. I can easily get one grant or the other but can't seem to get both to work in one grant. I would rather not force the user to approve two different app approval boxes.
Is this possible:
scope=https%3A%2F%2Fapi.partnercenter.microsoft.com/user_impersonation%20https%3A%2F%2Fgraph.microsoft.com/openid+profile+email
as per the limitations of azure ad, I don't believe you can request multiple scopes from different external resources like you're doing there. you will have to do two different requests. the token should stack with the resources, but you cannot call them both in one go. so no, that scope= you provided probably won't work or will only return the first scope.
Similar type question for reference.
https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/issues/1390

When connecting to an API do I need an access token per each user using my application?

I'm connected to an API that provides information about cars based on their registration. According to the docs the api can provide both user specific data and general data about the registration supplied.
I am using the connection method which does require specific users data, and therefore does not require me to gain access to any specific users account.
On my end users will visit my application and enter a registration number which I will use to call the API and return all of the information about the car.
Am I right in my thinking that my application is essentially the 'user' as far as the api is concerned, and I will only need to use one access token. I can then use this access token to make multiple API calls (one for each user that searches on my application)?
Or will i need to set up an access token for each user that visits my application and treat them separately.
Only your application making the API requests requires a token, unless the licence agreement/documentation of this car API says otherwise.
As far as your users are concerned, your application is just magically sourcing the registration info from its database.

Securing REST API that will be accessed by diffrent clients

I have developed a REST/JSON API. The API exposes a lot of features. The API will be consumed by applications we design internally (mobile apps and web apps), by applications designed by our resellers and by applications designed by businesses. I am looking at securing the application by implementing authentication and authorization. I have 'googled' a lot but my research has left me with more questions than answers.
Our internal application will be used by end users registered on the application. In essence, our application is just a client taking request from the end user, taking it to the REST API and retrieving the data for the end user. Our internal application should be able to perform all the operations exposed by the REST API. What is the best way to handle user login on our internal application? HTTP Basic over SSL or OAuth?
Our reseller applications can create users like they own the users but ultimately the user details get stored in our database. The reseller application will just act as a client taking request from the user and fetching user data. Our resellers applications should only be restricted to some operations of the REST API. What security mechanism will I use to implement this kind of authorization and user login?
I hope my question is clear. Thanks for the help.
From what I understood in reading this there are two parts to your question:
What is the best authentication method for my API?
I recently developed an authentication system for an API that was modelled on OAuth but didn't have every single one of their specifications. The system was basically the same as what Amazon use for their API. [This article]1 is very helpful if you want a secure API authentication model without having to use OAuth.
The model uses these principles:
Authentication data will be passed with every request to the API server
Requests will include a Unix timestamp from when it was generated
The entire request (including the timestamp) will have an HMAC hash generated and sent alongside the rest of the data. The hash is generated using a private key that only the API server and the API client know.
The API takes the data (including the timestamp), generates an HMAC hash using the private key for that user (identified by a user ID, user name, public API key, whatever) and compares it to the hash sent with the request. If this was successful, regular authentication proceeds and the request is processed. Note: the API will check the timestamp and compare it to its own to make sure the request has occured within a valid timeframe of, for example, 30 seconds, 5 minutes, 10 minutes, etc.
Of course, you can use regular HTTP authentication over SSL/HTTPS also, but I find this way to be very good because you achieve a high level of security without needing to implement every aspect of the OAuth protocol.
How you authenticate is up to you essentially. I prefer to go with methods employed by large, trustworthy organisations (such as Amazon). I personally didn't want to go the whole hog with OAuth like Twitter, Facebook etc.
How should I allow different users to access different endpoints in my API?
You should have an internal map in your API server which contains records allowing or denying specific API accounts from accessing certain endpoints. In my API server I decided that all endpoints would be "allow" by default, and I would specify which accounts would not be able to access certain endpoints.
You could also set up different groups or types of API access accounts which could have group permissions like this.
My suggestion would be to [read this article]2 twice, or three times, then read it again. Then, implement the methods suggested within.
Personally, I think the best method for ensuring as much security as possible is to restrict absolutely everything in regards to the request to be within a set of boundaries that you define, e.g. I want this endpoint to only be accessible by GET HTTP requests (all other HTTP methods will throw an error), up to 3 times daily per account, within a 30 second timeframe of request to server, only allow a narrow range of data to be returned, etc.
Limiting the HTTP method is very important to reduce the risk of your API doing things it shouldn't, especially with a RESTful API as endpoints can be used to do multiple things depending on the request method. You can even set your permissions for each API account to restrict certain methods on each endpoint, e.g. API user xxx can GET information from an endpoint but cannot POST, PUT, PATCH etc, or API user xxx2 can POST data but cannot GET any, etc.
[EDIT] 1 and 2: www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ (not completely removing the link but keeping the url unlinked as it no longer works/redirects to random sites)

Linkedin API to get public data

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