I have generated an Yammer API key within a network and the API key is working for read/write data across this network. But when I try to use the same API key to access data from a different network it shows an error.
unexpected token at 'Your network is not allowed to request an OAuth token for this Application'
Is the API key restricted to using on that particular network only ? Is it possible to use a single API key more generally to retrieve data from another networks ?
By default it is tied to your organisation. You need to publish the app to the app directory for it to be available for everyone. Are there only particular networks where you want it to work? This requires additional configuration on the Yammer side. A clunky workaround is to create app IDs in the other networks where you need to run your app and allow the user to select the appropriate one. It depends on what you are trying to do.
Note : Verbatim copy from the Yammer Developer Network, as answered to my question here, https://www.yammer.com/yammerdevelopersnetwork/#/Threads/show?threadId=292877375
Related
The current youtube API quota is 10,000 units/day.
So what if I created an app and this app has 100 copies installed on different 100 devices and all of them use different IPs, would the quota be 10,000 units/day for every device (1M/day) or the 10,000 units would be distributed among the different copies?
Note that the requests will be executed on different devices. this is an embedded app., not a cloud one.
10,000 units/day is project based, not user based. IP address won't affect anything.
As you can see from the above image on the Queries per minute per user is user based, and detected via ip address, sending the quotauser parameter along with the request or sending an authorization header containing an access token.
In order to get around your 10k quota in this manner you would need to create 100 projects on google developer console and create credietnals for each of those projects and then each project would have 10k quota. However the drawback would be trying to get 100 projects though the google verification process.
You could just request an extension of your quota if you need more quota. 😊
Additional Clarifications
API key Used to access public data only and identifies your application to google
Client id and client secrete used to create a access token, will identify both the application and the user to google once a user is authorized and you are sending an access token authorization header with your request.
The quotaUser and userIp parameters can only be used for anonymous requests with some Google apis this has changed recently i am not sure if it still works with YouTube api private calls. userIp allows you to send any ip address with the request, and QuotaUser allows you to send any string for example your internal user id for the user making the requests. In the past this allowed for some hacking / work around for the per user quotas.
None of the above information will really help you as the quota you are trying to get around is a project based quota and not a user based quota. Its detecting the project associated with your client id / api key (depending upon what you are using) changing the IP or generating a new client under your project isnt going to help.
Really just request more quota
There are two ways an app is identified by the API:
the API key that the app uses when invoking the API endpoints (for reading only public data), or
the credentials data (i.e. access token) the app makes use of when calling in various endpoints (for reading only public data pertaining to any YouTube channel, or, otherwise, for reading/updating/deleting public and/or private data pertaining the YouTube account/channel that granted permissions of operation to the respective app).
Therefore, from the point of view of the API, it doesn't really matter if you are running N different instances of your app (i.e. programs running on concrete computers). The API accounts for the quota consumption of a given project created through Google developers console.
In this context of an app (as a concrete program) running on several machines that share API keys and/or credentials data, I recommend warmly to get familiar with the content of the DTOS specifications.
I am making a web application that will automate some actions on Google AdWords. The web application can be used by anyone that has an AdWords account.
I am a bit puzzled by the AdWords API, as it is a different from other Google APIs, in terms that it needs two additional config parameters: developerToken and clientCustomerId, a per their documentation:
https://developers.google.com/adwords/api/docs/guides/first-api-call
When constructing the AdWordsClient object, I need to provide the developerToken and clientCustomerId, in order to push data to AdWords.
My question is whether these two parameters (developerToken, clientCustomerId) need to be different for each user that will use my web application?
It seems that I am able to post data to different accounts with an unrelated developerToken, which does not make sense.
Can I get the clientCustomerId from an API endpoint, so I don't require my users to manually input tokens and ids to the web app, and do the complete authentication with oAuth?
My code is working, I am asking more of the philosophy why I need these two parameters, and if I can avoid asking the user to manually copy them from the AdWords dashboard into my application?
The developer token identifies a given Adwords API developer and is used for RMF enforcement, rate limiting and the like. As you mentioned, this is different from other Google APIs, which I think has to do with the fact that it's not a publicly available API. You always have to use the developer token that was given to you as part of your API sign-up process and are not allowed to use another developer's one (thus there's no possibility to have a user of your application enter it on their own).
The clientCustomerId parameter refers to the specific Google Ads account that you want to interact with. As a given user (identified by the OAuth2 access token that you include in your request) might have access to a whole lot of different accounts, this always needs to be included.
As for how to obtain a list of accessible account given a user's credentials, you can use the CustomerService.getCustomers endpoint for that purpose. Quoting the docs, it will "return details of all the customers directly accessible by the user authenticating the call."
I'm developing an iOS app that uses Cognito User Pools / Federated Identities, Mobile Analytics, and S3 to manage various features of the app, and recently I have become concerned for the security of these features. I already use IAM roles to control the services unauthenticated vs authenticated users have access to, but most of these services use strings (e.g. user pool app client id or user pool app client secret for User Pools, or app id for Mobile Analytics) to give the app access to that service.
What are the best practices to securely store these strings on the device to be used when necessary? Is it even necessary to secure these strings since the app is using IAM roles?
If it is necessary to securely store the strings, I have read that using the CommonCrypto library to encrypt strings before putting them in the keychain is best, but I'm not sure what key to use for encryption since my user needs unauthenticated access to those services. Any advice would be tremendously helpful.
This is a common problem to any mobile app. If someone really wants to, it's not difficult to decompile the app and scrape the keys from it. It's great that you are using IAM roles to restrict feature usage. This will limit the blast radius of attackers, but not necessarily prevent them.
Wth user pools you also get a globally unique identifier which can be used with IAM to restrict what S3 you can use key pre-fixes (which act similar to folders) to limit the objects that users can access to pre-fixes with their unique identifier. You can refer to https://mobile.awsblog.com/post/Tx1OSMBRHZVM9V0/Understanding-Amazon-Cognito-Authentication-Part-3-Roles-and-Policies (Using user pools as the provider, which will use the identity id as the prefix). Depending on how you structure your app you could use this so each user can only modify their own objects. I don't think Analytics has any way of restricting like this... because it wouldn't really make sense for it.
As far as securing your ID's there are things you can do to help mitigate, but there is no fool proof way to prevent someone taking it. You could for instance have the app make a call to your server for the ID... but then an attacker could just call the server. You could encrypt it, which might make it more difficult for an attacker to get, but you have to keep the key somewhere and if the app could get it so could someone who decompiles the app. Unless your app users get some sort of password from outside the app and put it in there isn't a complete way to lock it against attackers.
Hope this helps.
TLDR: All I want to do is secure my cloud function in Parse so that it only accepts requests from my iOS app. How can I do that?
Longer version:
I recently got started with using Parse for a client side app I'm building using a Google API.
Before using Parse, my issue was that the Google API calls from my app were not secure. I tried a Man in the middle attack on my app, and I was able to successfully get the bundle id and app id (Google claims some form of security is achieved by ensuring that the call is from the correct bundle id that you can specify on their console). So despite using SSL, seems like it was easy to get this information. Now this Google API is paid, so someone could easily abuse my key when I release my app and raise my bills.
I was anyways also thinking of doing some lightweight work in the backend, so I figured to use Parse. Now the call to the Google API is done in Cloud Code. But a new problem I'm facing is how to secure calls to the Cloud function I've defined in Parse? The Parse App ID and Client Key aren't secure at all.
All of Parse's blogs keep talking about creating users and defining ACLs etc. But in my case, there is no data in my Parse app and there is no user per se. It simply calls the Google API and returns the result. All I want to do is secure my cloud function so that it only accepts requests from my iOS app. How can I do that?
The inherent security risk here is that any key you store in your app is vulnerable, for that reason encryption is also vulnerable. My recommendation is to use the automatic user in Parse on your iOS app, you could even throttle excessive requests/abuse by a single user. By creating and using a user you are able to gain the benefits of ACL which appears the best security option available in Parse currently. At that point you send the automatic user in your cloud code request and verify it's a valid iOS user.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.