In case one is asked to enter their PayPal API keys (API user, API password, API signature), what can the receiving end actually do with those?
The receiving end wants to use the keys for Express Checkout and that's fine, but I'm not sure whether giving such information would actually enable the other party to make use of other functionality (such as having a look at the balance of the account).
Generally speaking, you can have a look at PayPal's REST API documentation to see what can be done with an API key. I'm not aware of any way to grant subsets of permissions to an API key (but I don't know for sure that it's impossible, either).
There's also the SOAP API. I haven't used it, so I'm not entirely sure if it uses the same API keys or some separate authorization mechanism. It does contain a GetBalance API, though.
It should perhaps be noted that I don't think it should be considered impossible that PayPal extends the API-accessible functionality at any time, though.
Related
I'm still trying to wrap my head around all this, so my apologies if I've made a mistake, but it seems like the old NVP apps that are now unable to be registered as of December 1st had some features available that can't be replicated in the new REST world order...
Here's what I want/need: I need to be able to translate buyer-side transaction IDs into my seller-side transaction IDs, and I want to be able to do this on a webserver that is secure but I don't want it to have full access to my account, so I'd like fine-grained authz for this server.
It seems like I am a couple days too late to actually get what I want/need. Basically, GetTransactionDetails does exactly what I want (convert buyer to seller transaction IDs, and returns the rest of the transaction information for good measure). And, although I haven't gotten it working, it looks like the Permissions SDK plus an NVP AppID would allow me to have just the TRANSACTION_DETAILS permission on this service which is exactly what I want.
However, as of Friday apparently I can't get an AppID for the classic NVP API? If so, my timing is impeccable.
Trying to figure out how to do this in the REST API has proven difficult. This thread talks about the sale record, which does indeed take a buyer-side transaction ID, but it does not actually translate it into a seller-side one. It does have the custom field, which helps me a little, but I really need the seller-side transaction ID. It looks like maybe the parent_payment URL in the return from the sale might help, but the API started returning PERMISSION_DENIED on me even on previously successful queries so I can't exactly test this right now. And, even if that did work, it seems like the permissions on the REST API are incredibly coarse compared to the Permissions SDK, for example the sale endpoint is under /v1/payments which seems to also include refunds and all kinds of other stuff I don't want exposed. It looks like there's a Transaction Search permission but it's marked beta and it didn't work for querying a sale for me. But maybe it means they're working on it?
What are my options here?
Thanks,
Chris
Okay, so I played around with this for a while, and it seems like the PayPal REST API is just not very good. So, I worked around the limitations here using AWS Lambda and its fine-grained IAM permissions. I created a Lambda function that took my PayPal NVP credentials as encrypted env vars, and an IAM account that could only call my Lambda function, and so now I've got a microservice that will translate transaction IDs and return some extra info (custom and email) from the transaction to boot.
I wish I didn't have to use AWS to work around PayPal's limitations (which seem to be getting worse with the REST API, the NVP api would have been fine if I could have gotten and AppID and used the Permissions SDK), but oh well.
Chris
I have some REST services on my site that will be available for 3rd parties to access.
My plan is simple. In order to call on these services, they need to request a key from me. I will privately supply them with a GUID. Each call to any of my services will, via a filter, check the header for the key and accept/reject the request accordingly.
This site is all HTTPS so the key would be encrypted during transit. I'm not worried about the key being visually identifiable to authorized clients. In other words, I'm not worried about any kind of 'inside' attacks or people sharing the key. I just don't want random, unauthorized outside users.
I have looked around and I don't really see anybody doing it exactly this way. I feel like I'm over-simplifying... but on the other hand, I don't see what's wrong with it either.
My question is.. does this sound secure enough (from a basic/minimal perspective) or does it expose some gaping security hole that I'm not seeing?
FWIW - I am using the Spring Framework, including Spring Security 4.
Thanks!
If it's HTTPS and the API key is in the header encrypted during transit as you described etc, then it follows a pretty standard design authentication pattern.
Your security now depends on how you distribute and store your API keys.
Although, you could use an "Application Identifier and Key pairs" approach.
Whereas the API Key Pattern combines the identity of the application
and the secret usage token in one token, this pattern separates the
two. Each application using the API issues an immutable initial
identifier known as the Application ID (App ID). The App ID is
constant and may or may not be secret. In addition each application
may have 1-n Application Keys (App_Keys). Each Key is associated
directly with the App_ID and should be treated as secret.
Just in case you wish to extend the application in the future.
I'm trying to use UberAPi to request rides while not requiring an authentication from the end user (rider).
My company should be responsible for the payments from such rides, and would only request that a driver appears at point A at such time, and deliver someone to point B.
Uber business does have all the features needed for such an integration: Usage reports, expense codes, and else, but I see no way of doing this without either an SSO or OAuth.
No, it is not currently possible to use the api for such a use case. You might want to consider using Uber Central.
I have seen many different posts regarding different solutions for authenticating a RESTful API and I have some questions, given this current scenario.
I've built a REST API that will allow clients of my software service (we are a B2B company) to access resources programmatically. Now that I've got the API working properly, I'd like to secure it in the most standardized way possible. I need to allow access to certain resources based on the caller of the API. That is to say, not all users of the API can access all resources.
I have URLS available in the following formats:
https://mydomain/api/students
https://mydomain/api/students/s123
https://mydomain/api/students/s123/classes
https://mydomain/api/students/s123/classes/c456
So far I've come up with these possible solutions:
Provide a unique key to each client that they can use to ultimately generate an encrypted token that will be passed as a GET parameter at the end of each REST call to (re)-authenticate every single request. Is this approach too expensive
https://mydomain.com/api/students/s123?token=abc123
Provide a value in the HTTP Authorization Header as seen here. Is this almost the same as #1? (Except I can't paste a URL into the browser) Do people use these headers anymore?
Use OAuth 2 (which I'm still a bit unclear on). Does OAuth 2 actually authenticate the client as a logged in user? And doesn't that go against the spirit of a REST API being stateless? I was hoping OAuth was the proper solution for me (since it's a public standard), but after reading up on it a little bit, I'm not so sure. Is it overkill and/or improper for REST API calls?
My goal is to provide an API that will not have to be changed for each client that wants to consume the API, but rather that I can provide a standard documentation made available to all of our clients.
I'll be happy to post additional details if I've been unclear.
There are 2 type of clients you probably want to prepare your API:
trusted clients - Which are written by you. They can have the username and password of the actual user, and they can send that data to your server with every request, possibly in a HTTP auth header. All you need is an encrypted connection by them.
3rd party clients - Which are written by some random developer. You can register them in your service and add a unique API key to each of them. After that if an user wants to use their services, you have to show her a prompt in which she can allow access to the 3rd party client. After that the 3rd party client will be assigned to the user's account with the given permissions and it will get an user specific access token. So when the client sends its API key and the user specific token along with the request, then it sends the requests in the name of the user.
OAuth can help you to control the second situation.
Your URLs do not have a meaning to the clients. By REST you have to decouple the clients from the URL structure by sending links annotated with semantics (e.g. link relations). So your documentation does not have to contain anything about the URL structure (maybe it can be useful for server side debug, but nothing more). You have to talk about different types of links. By generating these links on server side, you can check the permissions of the actual user (or 3rd party client) and skip the links which she does not have permission to follow.
We intend to develop rest based api. I explored the topic but it seems, you can secure api when your client is an app (So there are many ways, public key - private key etc). What about websites / mobile website, if we are accessing rest based api in website which do not use any login for accessing contents ( login would be optional ) then how could we restrict other people from accessing rest based api ?
Does it make sense using Oauth2.0 ? I don't have clear idea of that.
More clear question could be ,How can we secure get or post request exposed over web for the website which doesn't use any login ?
If it's simple get request or post request , which will return you json data on specific input, now i have mobile website , who will access those data using get request or post request to fetch data. Well, some else can also access it , problem is i am not using Login, user can access data directly. But how can we restrict other people from accessing that data.
What do you think is the difference between securing a website that is not using REST vs one that is using REST API?
OAuth provides authorisation capabilities for your site, in a REST architecture this means a user of the mobile application will have to provide their credentials before being allowed to access the resource. The application can then decide on if that user has access to the requested resource. However you've said your website doesn't need use authorisation.
You can use certificates however good luck managing the certificate for each client. My take on it is for your explanation you don't need to secure your website because you will never be able to manage a trust relationship between the client and the server. There are some options though:
You build your own client application that you ship out to people which can verify itself with the server using a packaged certificate with the client. E.g. iOS has this kind of feature if you build for that device.
You provide a capability to download a certificate that is 'installed' in the browser and used when communicating to your REST API
Use something like a handshaking protocol so when a client wants to make the first request it says; 'hi I'm a client can we chat?' And the server responds with 'yes for the next X minutes we can however make sure you send me this key everytime you tell me something YYYYYY' (you can use something like SecureUDID or equivalent for other devices than iOS).
There are probably others but you get the basic idea. Again in my opinion if your resource doesn't need authorisation then you don't need to secure that REST API. Can I ask what kind of data are you exposing via this REST API or functionality your providing? That might help provide a better answer.
You want authorization: only some agents (mobile clients) and/or users should be allowed to access those APIs.
To solve that problem, you need identification: a way for the server to tell who is who (or what), so the right decision can be made.
There are many different way to provide some form of identification, depending how much you care about security.
The simplest is a user agent string, specific to your mobile clients. But it can be faked easily. Slightly harder to fake are client based 'secrets' - embed some kind of secret or key in your mobile client code. You can make it really complicated and secret, but as ramsinb pointed out, you can't get security this way as it would require you to be able to guarantee that the secret you're shipping with the client (wether it's code, algorithm or any other fancy construct) can't be compromised or reverse engineered. Not happening when you don't control the client.
From there, 3 choices:
Security isn't really required, don't bother
Security isn't really required, but you still want to limit access to your API to either legit users/agents or people ready to invest some time hacking your protection - go with a specific user agent or a client embedded secret - don't invest much into it as it won't block people who really want access to get it anyway
Security IS required - and then I don't think there is a way around authentication, wether it's login/password, user specific (device specific?) keys, OpenID, etc... No matter what, you'll have to add to the user burden to some extent, although you can limit that burden by allowing authentication to persist (cookies, storage....)