I am using the Blogger Javascript API to retrieve my blog posts and anyone can easily see API key in the view-source, and it can be used for deleting and updating posts. I would like somehow to prevent others from doing so, is there any way to do that?
Even if someone got your api key he can't make any changes to your blog, because updating or deleting posts requests requires authorizing with OAuth 2.0
If the request requires authorization (such as a request for an individual's private data), then the application must provide an OAuth 2.0 token with the request. The application may also provide the API key, but it doesn't have to.
Related
I have created a web app which is making use of OneDrive API (https://learn.microsoft.com/en-us/onedrive/developer/rest-api/) to perform actions such as create/update/rename/delete of documents etc. I am authorizing requests with OAuth 2.0 (client side - that means every access token is valid for ~1h and then silently I am getting a new token) and then perform previous actions using that token.
I have a new requirement for the authorized user to share his/her documents for writing/updating them (I found out that API has option for inserting permissions (https://learn.microsoft.com/en-us/onedrive/developer/rest-api/api/driveitem_invite).
Is it possible for a non-authenticated user to be able to write/update documents (programmatically - via OneDrive API or some other API?) that have been created from the authenticated user that shared these? (something that is similar to Microsoft Word online when a user is sharing his document and offline/ guest users are able to edit it?
Thanks.
Some Update:
First of all documentation for REST API/ endpoints is chaotic. (https://github.com/OneDrive/onedrive-api-docs/issues/839)
I found out that I can get shared document via these endpoints:
GET: https://api.onedrive.com/v1.0/shares/encodedUrl/driveItem
And update shared document only if I have an access token
PUT: https://api.onedrive.com/v1.0/shares/encodedUrl/driveItem/content?access_token=accessToken
where encodedUrl can be obtained as : https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/shares_get
(check example on C# with sharing url )
So, I am still wondering how possible is to update a document without any authentication but just a share url.
I want to extend a project in a way that it can save files to Google Drive. To learn how this works I tried the Quick Start Example from the docs: https://developers.google.com/drive/v3/web/quickstart/js
Following the example I noticed that the example is creating an API key in the developer console. Following the same steps only returns a Client secret. I suspected this to be a naming problem and hoped that the two are the same.
Unfortunately, the example code does not work but loggs the following error:
{"error":{"errors":[{"domain":"usageLimits","reason":"keyInvalid","message":"Bad Request"}],"code":400,"message":"Bad Request"}}
In the request to:
https://content.googleapis.com/discovery/v1/apis/drive/v3/rest?pp=0&fields=kind%2Cname%2Cversion%2CrootUrl%2CservicePath%2Cresources%2Cparameters%2Cmethods%2CbatchPath%2Cid&key=[[my key]]
I checked that the right secret appears in the request url. Setting var API_KEY = '<YOUR_API_KEY>'; to an empty string is a workaround.
How can I debug this further? where do i get the right api key?
I run into this error recently. It is certain that Google Documentation is usually quite good, but in this case, the Google Drive API (https://developers.google.com/drive/api/v3/quickstart/js) it wasn't that clear. For this API in particular, you will require two credentials.
Under your project credentials section, you must create an OAuth 2.0 client for a web application and a API Key.
(Sorry for the Spanish in the screenshots)
Regarding the OAuth 2.0 client, not that I have restricted it to http://localhost
Concerning the API Key, note that I have restricted it to my Google Drive API
Then, in the index.html provided by the documentation, you can set your CLIENT_ID to the one obtained in the OAuth 2.0 client generation, and the API_KEY to the the one generated in the API Key process.
{"error":{"errors":[{"domain":"usageLimits","reason":"keyInvalid","message":"Bad Request"}],"code":400,"message":"Bad Request"}}
Means that the request you have made has not been properly authenticated.
API key is for accessing public data. Oauth2 client id and secret will be used to access private user data which file.list is. So i dont think this is a naming problem. Your code should be popping up requesting access of the user.
We have a web server using Google Sign-In to authenticater and authorize for API access (Classroom). We need the sign-in part, so we're using init() and signIn(). We cannot use authorise(). Also, we're not signin in with particular scopes, as we just need identify for normal usage.
The logged-in user can enable a feature that requires offline access on behalf of his/her account to the Google Classrom API. We call grantOfflineAccess() with two scopes related to Classroom to get an authentication code, which is stored for later.
On the server side, we have a gRPC service that doesn't expose any web front-end. We're using C#/.NET with the Google API Client libraries.
I implemented an IDataStore that can respond to TokenResponse requests by either calling AuthorizationCodeFlow.ExchangeCodeForTokenAsync with the above code, or return the last TokenResponse stored in the database. When (well, "if") IDataStore.StoreAsync is called with a new version (normally after a token refresh was required), it saves it again in the database.
My problem is that ExchangeCodeForTokenAsync returns me a TokenResponse without a refresh_token. This means the access_token is only valid for 60 minutes. I would need to intercept exceptions at the service call level to call ExchangeCodeForTokenAsync again (if that works!), instead of relying on the Google API Client Library handling refreshing automatically all nicely.
What could be preventing ExchangeCodeForTokenAsync from returning me a refresh_token?
Thanks.
Well, I found the answer in this other question.
The refresh_token is only provided on the first authorization from the user. Subsequent authorizations, such as the kind you make while testing an OAuth2 integration, will not return the refresh_token again. :)
I simply removed my app from my Google account's authorized apps, and my next ExchangeCodeForTokenAsync call returned me a refresh_token.
I am using Apigee as a proxy for a private REST API which allows basic CRUD operations on my database. The front end developer wants to call my API directly from JavaScript/Ajax so I can't use a basic API Key authentication because anyone could view the source of the JS and invoke potentially destructive methods on my API (I'm a away of origin policies in browsers but that wouldn't prevent someone doing a curl and invoking my API outside of the browser).
What is the best approach? Can the UI developer use OAUTH in some way to obtain an access token for each session once the user is authenticated and use that in his Ajax calls? But even then, couldn't that user view the JS source and do something nasty via curl?
Thanks in advance!
OAuth v2 should solve your problem. There are multiple articles and resources on the Apigee web site which discuss when it is best to use OAuth v1 vs. OAuth v2.
http://apigee.com/docs/content/apigee-oauth-frequently-asked-questions, a three legged OAuth strategy may work best for you: http://apigee.com/docs/gateway-services/content/oauth. There is an example of that on the Apigee web site.
So you want to authorize a visitor to your 3rd party site, and make sure they can't do anything abusive?
There is no security model for this. Once you authorize the user/session/browser it's free game, he can do whatever he wants.
So take a step back here, what abuse to do you want to prevent? Maybe you want to prevent unknown 3rd parties from using your service. In that case you can set up API key authentication underwater which gives you a temporary session key.
There are 3 parties. The user (u), the 3rd party (3) that uses your API, and you (y).
u requests a session key from 3
3 does an underwater request to y with his API key
y verifies the API key and sends back a session key to 3
3 hands the session key to u
u does the service request to y
If 3 can never obtain a session key your service is safe against unknown 3rd parties.
I have a browser extension (google chrome) that fetches and displays some public tweets, based on user input.
I've been using the Search API just fine, but according to the API changes, I have to migrate to API v1.1 where authenticated requests via oauth is required.
I have no previous experience with oauth, but it seems like a bad idea to implement it in pure client-side javascript, as the consumer key/secret will be exposed.
If I implement the authentication via a browser npapi/ppapi plugin, will it provide the needed security ? or does this mean that I have to dump this project and simply move on ?
Thanks.
You need to obtain an access token so that you can read data on behalf of your users. This involves implementing Twitter's 3-legged auth, which is very similar to implementing Twitter sign in (which thankfully is well documented).
The link below will take you to Twitter's overview of the differences between the two approaches to authenticating. From there you can get to the code samples that you'll need to implement this securely yourself.
https://dev.twitter.com/docs/auth/3-legged-authorization