My goal is to offer a service for user of my website to store their private notes.
I want that users can trust the service, therefore the data should not be accessible for my company.
Can i realize this with google-cloud-storage and oauth-2.0 authentication? I would use the Google Cloud Storage JSON API to send the notes directly from the browser into the cloud.
What would be the basic steps to implement this?
There are a couple of ways to handle this, depending on how you want to handle authentication. If you want to make sure that your application cannot access the objects and only the users can, you'll need the users to have Google accounts and authenticate your app to act as their agent using OAuth 2.
Your app could involve a piece of JavaScript that would prompt the user to authenticate with Google and grant it access to Google Cloud Storage under their name. It would then receive a token that it could use to act as them. From there, it would upload the note using that token with an ACL granting permissions only to the uploader.
The uploaded object would go into your bucket, but it would be owned by the end user. You'd have the ability to delete it, but not to read it, and your bucket would be billed for storage and access.
The downside here is that all of your users would need to have Google accounts that they could entrust to your application for short periods of time.
Here are some details on the OAuth 2 exchange: https://developers.google.com/accounts/docs/OAuth2UserAgent
Here's the JavaScript client that does a lot of the authorization heavy lifting for you:
https://code.google.com/p/google-api-javascript-client/
And an example of using that library for authorization:
https://developers.google.com/api-client-library/javascript/samples/samples#AuthorizingandMakingAuthorizedRequests
Another alternative would be for the user to upload directly to the cloud using YOUR credentials via signed URLs, but if you went down this road, you would be able to read the notes after they were uploaded.
Related
I need to build APIs integrations to connect my Rails 6 B2B app to any other service such as Google Drive, Microsoft Excel, Zapier.
What I've done so far is to ask clients for their client_id and client_secret (or api_key), store them and then use them to authenticate to the API with OAuth2.
Storing clients' secrets is not the ideal solution. I would like to do the same thing but without asking for secrets.
Just like Trello or TypeForm are doing it.
I have no clue on how to authorize my app to read/write data of an other service without authorizing through an URL with the secrets.
Here is an example of TypeForm connecting to GoogleSheet API :
Connects to the Google account
Asks for permissions
Asks for the spreadsheet link
Writes data in the spreadsheet (form responses)
https://www.typeform.com/connect/google-sheets/send-responses-to-google-sheets/
The usual way is that you register your own "app" in the console for those API providers, and then you use your own client id/secret pair to request access to the end user's data. That's what usually brings up those authorization screens like: "jdps app1 would like to access your google account".
More information for Google APIs specifically: https://developers.google.com/identity/protocols/oauth2
At work we have never used 3rd party Auth solutions and I'm trying to inform myself of how they work for my personal projects. Getting the response is easy enough, but feel a bit lost on what to do after I get the response back. Am I supposed to send the auth token to the backend so it can be verified then trigger my app's login process for the given e-mail address/username? Logging them in essentially without a password?
There's two basic use cases for OAuth 2.0 which will determine what you do after the user is authorized. Your use case can also determine which OAuth 2.0 permission scopes you request the user to authorize your app for.
1. Single Sign-on
A simple use case for using a 3rd party OAuth solution is to leverage the 3rd party to perform authentication. Two reasons for this include:
Your users may wish the convenience of logging in with another provider (like Google, Facebook, Twitter, etc.), one where he or she may already have an active session.
You may not wish to implement your own login / authentication / password reset process.
Either way, a common way to implement this is to make an API request using the token to retrieve the user's email address after a successful authentication, which you then map to your own user database to establish an authenticated session for your service. Since you only need to retrieve the user's email address and minimal other information (e.g. name) in this use case, you can ask for a minimal set of scopes.
I do this in my oauth2more library where after receiving a token, I have a generic interface to load a user data which I convert to a SCIM user object. Because I've abstracted the code to retrieve user info in this manner, it's easy to support SSO across mulitple auth providers.
2. Using Service Features
A slightly different use case is that you want the user to authorize your app so you can make commands on behalf of the user via API. In this case, you will use the token to call more general APIs to accomplish your goals. A caveat is that you will need to make sure you ask for the proper permissions when asking the user to authorize your app.
As an example, one thing I've done is ask the user to sign in with Google so I can then make API calls to create and edit Google Sheets and Google Slides using APIs on their behalf.
When an application uses the Drive Realtime API in conjunction with a user's file stored in Drive, it gets access to the realtime collaborative model which is associated with that file. It has been documented in both the official reference material [1] and in a previous answer here on StackOverflow [2] that when two different applications [3] use the Realtime API with the same Drive file, they will be accessing different collaborative models.
Let's assume that I have a server-side application with a client_secret and the user's OAuth refresh_token stored on a server that only I can access, and that the user's access_token only leaves that server when making direct calls (over HTTPS) to various Google APIs. Consider the case where my application has used the realtime.get and realtime.update methods of the Drive API to keep some sensitive data in the collaborative model of the user's Drive file, such as an encryption key or a long-lived OAuth refresh_token for a third-party service.
Is this sensitive data safe from disclosure to another application, even when that application also uses the Realtime API on the same file?
I don't think any other application could impersonate my application, since they wouldn't have access to my client_secret and wouldn't have a chance to intercept either the refresh_token or the user's access_token that is associated with my app.
Bonus question: Can the user bypass my application and gain access to this sensitive data?
I can't see a way for the user to impersonate my application. The user can use my application's public client_id and grant himself permission through the normal OAuth flow, but would have no way to exchange the resultant code for a valid access_token without knowing the client_secret.
"Models are isolated by application. If a user opens the same file with two different collaborative apps, separate documents are created."
Using Collaborative Models with Existing File Types
"When you create a doc in the realtime playground, it is owned by the realtime playground app. When you try to then get the response in the try-it feature, it uses an app specific to try-it which can't see the realtime model you created." Official answer to question "How to work with Realtime get and update api requests?"
That is, when the applications use different client_id values to obtain OAuth credentials for the user.
The realtime models for different applications are isolated as you describe, but you should assume that anything in the model is theoretically readable by any user on the ACL.
If the user has authorized your application, they can theoretically grab the oauth token used to make requests since it needs to be sent from their computer along with the requests.
Additionally, if you ever load the document its available in the browser in its entirety, regardless of what parts of it you display.
I'm making an application wich allows the admin to manage the files of users in the google apps domain.
Since the docList api is deprecated I used the Drive api.
How I can create a Drive service as another user while logged in as admin?
Some people suggested to use the OAuth consumer key.
But I don't know how to implement this with oauth-2.0.
You might want to check out this post: Google Drive service account returns 403 usageLimits
I used OAuth2 and a service account to accomplish pretty much the same. Keep in mind you need to use the API Console to setup your environment and ensure the service account is added to the Google Apps domain with the proper scopes to allow access.
I have a webapp which does a lot of ajax requests with the php server and database server. I have also created an iPhone app and an Android app, which have been working as offline apps till now.
Now I want to create an API which will be used to sync data between web server and smartphone apps. Should I be using OAuth for this? What I have read about OAuth - it seems like it is used if I want to open my API to be used by third party apps. But here I just want to ensure secure transfer of data between API and my own apps.
Can somebody shed some light on this?
The main usage of OAuth is to make third-party apps authorized to access private resources of a user on a website without giving user credentials to the third-party app. For example, suppose that Twitter wants to get the list of contacts from your Yahoo account. The traditional way is to give your username and password to Twitter. But with OAuth, you give them a temporary token (called Access Token) which authorizes Twitter to access your contacts on Yahoo for a limited amount of time (until either this token expires or you, as the owner of private resource, explicitly revoke it).
That said, OAuth is not about securely transmitting data on the web. That's another story which is usually achieved using SSL. Even when you use OAuth, you have to use SSL alongside to make sure data is sent and received securely.
So in your case, you have to see what the API is used for. If it's public API which doesn't give any private data to the callers, there is no need to use OAuth. If the API is for accessing private resources of individual users however, You may consider using OAuth. If you opt to implement OAuth, you may allow other third-party apps to access your API in future without any concern.
Well a lot depends on how you are securing your API. Is your API open to public specially the post urls? If your data is not something which every user should see, then how are you checking the authentication of the user credentials?
Most the important thing is that we should avoid sharing the username and password over the wire to check for authentication all the time. This means, your API should not require username and password to validate if the user is valid. Which you can do by sending the username and password from mobile or device id or some other thing.
In such situation, the OAuth server comes to the rescue. Basically, on one URL a user will send his username and password to get his access token. Once that is acquired, we can use the access token to validate each request and take necessary actions.
You can refer the videos where I have implemented OAuth server in Laravel 5 using bshaffer which is one of the best OAuth library for any PHP framework to user. https://www.youtube.com/watch?v=0vGXbWdtjls