Today we are going to talk about authentication and authorization with OAuth 2.0 protocol that is used by Google and many other services. By means of it, services and applications like MSP360 Explorer can get access to third-party systems with no need to disclose user logins and passwords.
The information described in this post will prove useful when using any modern web-services. But we will consider the specifics of Google Cloud Storage authentication.
Google Cloud Storage Authentication
To get access to files in Google Cloud Storage a user shall confirm its identity (authenticate) and access rights (authorize). And here are a few mechanisms implemented for this purpose:
-
- — the most progressive option and we will consider it later.
<ligsutil — authentication by means of the utility having the same name. It provides an algorithm similar to OAuth (the password is entered on a special external site, the authorization code is received and then it is exchanged for an access token) but here all actions are manual.
- Client Library — a method used to test the product or work with general information that does not depend on the user. You just use Google Application Default Credentials like Network Service account in the Windows environment.
- Cookie-Based — An excellent option to provide a browser-based access to files for selected users. All links are publicly available but you can specify e-mails having read and write rights. In this case, when the user makes an attempt to load something, it will be offered to authenticate on a Google page.
Most mechanisms have their drawbacks that limit their application area or make their implementation complicated. That’s why it is recommended to use OAuth 2.0 whenever possible.
What is Google OAuth 2.0
Generally, OAuth was developed for those who are tired of registering on innumerable websites and forums and who is not ready to risk security for the sake of convenience. This standard provides a service or application with a possibility to verify your identity and check credentials without an access to the user password.
It means that you can be authenticated by any website after entering your password on a Google special protected webpage. In addition, in a similar way you can provide the application with access to your own information in a cloud. To get access to resources, the authorized application uses an access token that is transferred as an HTTPS request via an SSL encrypted channel.
OAuth & Google Storage
Let’s consider the operation of OAuth through the example of Google Cloud Storage.
Several authorization scenarios for web-servers, applications, and devices having no physical keyboard are supported in OAuth. All of them are united by the following algorithm:
- An application with the support of OAuth (for example, MSP360 Explorer) provides Google authentication server with rights to work with it. Usually, it is a public key generally embedded into the source code.
- Receipt of an application authorization code. This code is attached to the user account and is provided by Google when the user confirms its intent on a special webpage. Surely, you could often see a popup window offering to authorize a Google application on your smartphone – that’s it.
- Then the application sends the authorization code to Google Storage API and exchanges it for a personal access token which has rights to certain Google objects.
The list of requested access rights is created in the Scope parameter on the second step. Look at the picture below — Google depicted the whole process.
There are also niceties with access token expiration but their solution is transparent for users and it extends beyond this article.
The Role of Service Account
Google cloud systems can authenticate both users and applications. The second option can be applied in cases when the service must run regardless of the user password and activity. If you ever customized separate accounts for applications on a Windows server – it’s just about the same.
To delegate cloud access to the application, it is required to create an account on Google Developers Console. Similarly to a user, the server account will get an e-mail having quite a long prefix and a pair of a public key and a privacy key. These are the data that shall be provided to the application for its operation under Google account.
Look at the picture below — service account mode just replaces user authorization code with JSON Web Tokens (JWT). Also, you have to create a service account and generate JWT on your own.
Note: There is a peculiarity with the Service Account and Google Apps admins shall keep it in mind – domain administrative policies are not applied to these accounts. It means the following: if you prohibit files sharing with the outside world by means of domain policy, this prohibition will not be applied to Service Accounts.
Conclusion
With the emergence of OAuth 2.0 Internet services integration became much easier as the same account can be used to get various resources access without the security losses. The standard is under development now, that’s why it may be required to readjust settings of services running with OAuth in future. But still it’s a good compromise to the equilibrium of versatility, convenience and security.
- File management in Amazon S3 and S3-compatible storage
- Encryption and compression
- IAM and security management
