Just wondering if there are any restrictions to the API such as our product has multiple clients and wondering if the integration option is only allowed for 1:coinbase integrations
There's not much information in your question, but I will point out general information: each request through the REST API requires the key,secret,passphrase for a given account. I see no reason why multiple accounts could not be handled as long as you use the right credentials for each request.
Related
I'm building a game, and someone has exploited the API
How may I choose a list of "allowed domains" that can fetch through my API? My previous API was used by someone to increase their in-game money.
Learn about CORS Policy and implement it on your API Backend. Most probably, if you are using any of the popular frameworks to build your backend, you will already have this setting. You may just need to enable it and add your frontend IP/URL to it.
The comment and answer referring to the usage of CORS aren't solving the problem of someone exploiting your API. Everyone can write a program to simply set the Origin header themselves.
Increase your security by securing the API with any sort of credentials, e.g. api tokens. And then build your logic in a way that it isn't possible to perform those tampering actions.
Validate on server-side that the request is valid (why would anyone be able to simply increase the money by hitting an endpoint, they should do e.g. a quest and your server validates that it was successfully done and rewards the money).
I have a React Application which is going to leverage Google My Business API to get review data of a business.
I was expecting to use the API-KEY via REST approach however Authorization Scope mentions that OAuth 2.0 is required to use this API.
After I read more about OAuth's purpose, it seemed like it is more for application's which require access to a user's data and therefore would required a consent screen verified by google.
For my use-case however, all I need is access to all google reviews for a business and nothing related to the visiting users.
Can someone recommend an approach for this? (I don't want a pop-up/consent request when a user visits as I don't need user data.)
After much research, it seems that if you want to retrieve ALL REVIEWS for your business you will have to use Google's My Business API. This API requires you to use OAUTH2 for authentication which means (although you will not be querying a visiting user's data) visiting users will be required to provide consent pop up screen.
This leaves you with the places API as the next best option:
REST GET endpoint maps.googleapis.com/maps/api/place/details/json?placeid={your place ID}&fields=review&key={YOUR API KEY}
Although this only returns google's top 5 "most helpful" reviews, its pretty much the only way to get reviews without a consent screen unless you want to scrape data which is not ideal for many reasons...
I want to have some restrictions on my endpoints API where even if a user is authenticated, they might not be allowed to perform certain actions. I'm mostly guarding against someone being malicious and writing their own client against my backend (my own client will never do what I'm guarding against).
However, I'd still like to be able to perform those actions as myself for debugging purposes.
A simple approach would be to hardcode some "admin" email addresses on the backend.
Is there a better way? Ideally, I'd want to be able to specify the list in the console, and then in code I could have some API on the google User class such as user.isAdmin().
Does such a thing exist?
Thank you.
Using endpoints, you have the opportunity to include a User object parameter in java or use from google.appengine.api import users in python and then user.get_current_user(). If the user is administrator, you can check this (python example) (javadoc for function isUserAdmin()). Do this inside your protected API functions.
You can read more about authorization in endpoints here. In general the docs are a great place to find this kind of info.
I know this is probably an age-old question, but...are there any best practices for securing client secrets for performing OAuth2 authentication in AngularJS applications? I've been racking my brain trying to think of a solution to providing truly secure access to an API from modern style web applications (they need not necessarily be AngularJS.) In my experience, adding layers of abstraction and obfuscation really don't do anything to improve security...they just make cracking the security egg more difficult for any prospective hackers (however many of them prefer a good challenge, so all your really doing is just making the hack more fun.)
Aside from the obvious ineffective solutions such as obfuscation and convolution of code and things like that, are there any best practices for securing client secrets in modern day web applications? I know these questions arose with desktop client apps, and I don't believe there was ever a solution beyond "Might as well obfuscate, that'll slow hackers down". Are we in the same boat with web apps? Is there no real solution to this problem?
If there is not a solution...is there even really any point in securing REST APIs with OAuth?
Remember that OAuth is less about protecting against impersonation and more about protecting credentials. 3rd parties authenticated a user's identity for you without exposing the user's credentials. Since Tokens are not credentials, the amount of harm a hacker can do and his window to act are limited.
But OAuth is not inherently more secure for your application than regular username/pwd authentication. And on client-side apps, all your code is available for the world to see! As
you mentioned, client-side encryption is a questionable strategy.
While there aren't established best practices for protecting client interactions, here are some approaches to minimize your exposure:
1) SSL: Silver bullet? Maybe. The more you can use SSL in your site and your requests, the safer your users' requests will be. I honestly believe all privileged requests should be made by encrypted requests.
2) Short Token Life-Span: The shorter the life-span of your Token, the less incentive/advantage of sniffing it.
OAuth 2.0 creates a constant chatter out of authentication by exchanging Authentication Tokens for Refresh Tokens for Authentication Tokens. You, as the developer are now developing a chatty app that does a lot of "what's your token, here's another token, ask me for a token, here's your new token... so what do you want?" ... "oops, time's up, where's your Refresh Token?"
If that sounds like a pain, it kind of is. OAuth 2.0 is designed to make the process easier for you the developer. But the important point is, the shorter the life span of your tokens, the harder for a hacker to maintain a fraudulent identity.
Refresh Token reference
3) Enforce your Domain: Want to give sniffers less chance of abusing the chinks in your armor? Don't allow Cross Domain Requests!
Sure, we often have distributed environments. But if your Facade is on the Client's Domain, your exposure is lessened (word choice questionable).
Force the hacker to use your domain, limit their creativity.
4) Use 3rd party API's for maintaining you access as often as possible: Google and Facebook API's and Services have been unit tested, battle tested, and evolved. The more you can lean on them to maintain your user's Identity, the less work you will do and fewer chances you take.
5) Check IP addresses: Almost anything can be faked, but the hacker must know that IP Address is part of your validation. This is the least assured of all practices, but combined with 1,2, or more, the gaps for hackers to exploit get smaller and the payoffs for effort fade.
6) Use a "Secret" or 2nd parameter: You can pass your users more than tokens. You can pass your own Alter-Token.
Pretend it's an ID data being passed back and forth. Name the param in a non-obvious way. Make it a number (e.g. age, height, address). The important point is, your hacker knows little or nothing of what's being asked for on the other side!
You can throw a serious monkey-wrench by having 3 params that act as security.
7) Don't give error messages to inform the hacker they've been caught. Give timeout msgs rather than "Got You!" If the invaders don't realize the fraud was caught they don't adapt as well.
I can't say it enough -- SSL saves a lot of trouble.
Note: All client Providers I have seen allow access to their API's without exposing Secret. Secret should never be exposed on client.
Any data exposed on client can be gleamed
Any encryption algorithm you use, will be exposed on the client.
I came here looking for the answer to this very question - how to handle the secret/id in an SPA. I came up with my own solution that hides the secret in the server but I wanted to confirm what I was doing was best practice. So since answers avoid this I will explain my flow in hopes that it will help anyone out there.
Our architecture - we have a ruby server as the api server and an express server serving up the Angular app.
Normally all communication is simply done RESTfully thru the api so the node server is just serving static files and not really doing a whole lot.
Since we were at the point of implementing the login/signup flows I came across the - what was new to me - OAuth 2.0 flow of how to handle things.
Before we can make any requests to the server and the server will take us seriously we need to get ourselves the Bearer token. I chose to implement it as a node endpoint thus to hide the client secret inside the node server itself.
So our customer has entered all their juicy data and are redy to become a user in our app they hit the submit button.
The app fires the request to the node server to get ourselves a yummy token that we can use as the Bearer. I chose to pass the client id as a GET request query parameter. First off I had both client id and secret in the node server but it felt like the id could/should be on the, well, client. So I went with this way.
The node server receives the client id thru the GET request and then proceeds to fire the POST to the host(ruby api). Constructing the url + grant type + client id + client secret. Thus hiding the implementation from the world.
The ruby server return a token for us to use which we then return to the client that initialized the signup request.
The SPA now has a Bearer token which we can use in the header of the signup request.
Thus completing our flow and having a hidden cient secret from the world.
Since we have a token with a certain lifespan we also have a request error interceptor that will catch tokens that have expired and thus make a new token request and then refire the failed call.
I have chosen to use on the Angular side of things this lib for users flow.
https://github.com/sahat/satellizer
Its a super handy lib that gets all the boring boilerplate code that has to be written every time we want an app to have authentication thru email/password and also thru oauth....very handy.
So since this is my own interpretation of how to do such things - feedback is kindly requested.
My question is : can I use endpoints API or a service with OAuth protocol in general, in sort of that i not need to authenticate the user all time that it send a request to the server but only the first time and for the other times I will use type of token or whatever to use the server directly without check oaut. ALl that in a secure way of course.
the process of check oaut is slowing the response.
Thanks
It depends what you mean by "authenticate the user". OAuth as implemented by Endpoints (and demonstrated with samples) suggests you authenticate the user the first time they use the application (either at install time, or each time they load the app in the browser). From then on, the identity of the user is represented by a token, managed by the client library, and sent along with each request. The server will always verify this token to determine who is making the request, but it does not require user-facing interaction.
If you're asking whether you can use OAuth without continually making the user identify themselves (via an OAuth popup, etc.), yes, this is the way it works by default in the samples.
If you're asking whether you can use OAuth without verifying the tokens on each request, you could, but it's not worth doing, because it doesn't get you a lot from a security perspective or save you much performance-wise.