Are you in the process of developing an application designed to incorporate one one or more of the Google APIs? Do you already have an application and want to add Google data to it? Before you can access most of the Google APIs you must register your project on Google Developers console.
This post number six in my six part beginning Google Development series, which started with the post Google Development for beginners and continued with registering a project with Google, Google Developers console APIs and then we created public API key credentials, and OAuth 2.0 credentials. Now we are going to build upon our new project on Google Developers console by adding service account credentials.
In this post we will discuss when we would want to use a service account and how to add it to our project on Google Developers console.
Let us get started ….
What is a Service account?
Googles definition of a service account is slightly different then my own. The following comes from Googles page Using OAuth 2.0 for Server to Server Applications
The Google OAuth 2.0 system supports server-to-server interactions such as those between a web application and a Google service. For this scenario you need a service account, which is an account that belongs to your application instead of to an individual end user. Your application calls Google APIs on behalf of the service account, so users aren’t directly involved. This scenario is sometimes called “two-legged OAuth,” or “2LO.” (The related term “three-legged OAuth” refers to scenarios in which your application calls Google APIs on behalf of end users, and in which user consent is sometimes required.)
To me this means that if you are using a service running in the background that you would want to use a service account. In my opinion this is not his is not entirely true, in some instances you can also use OAuth 2.0 credentials in a background process on the server and sometimes you might want to use a service account on a website realtime.
My definition of a service account would be for pre-authorized access to public and private Google data without user consent at run-time.
Meeting room example
A company has a group of meeting rooms, each room can be booked for meetings. Now I would create a service account for this. A service account has its own Google Calendar account so we can create a new calendar called bookings for each of the rooms. When an employee wants to book a room I would insert an event into the calendar for that room.
Drawback to this would be that there is no Google Calendar web view for the service accounts calendars so I would have to create a web application or windows application to allow the employees to see when a room is booked and who has it booked.
Customer support example
A company has an issue system for customer support where users can upload files contains a stack trace of the errors. I could create a service account. I could and have the Service account create a file with the support information, then I would have the service account upload the stack trace file to Google drive.
A service account has its own Google Drive account. There are a few issues with service accounts and Google drive file upload. The first is like with Google Calendar there is no web interface so any files uploaded you won’t be able to see. A way around this would be to create a directory on the service accounts Google Drive and insert permissions to the directory giving yourself the developer access to see the directory and all the files within. You could also give the service account access to a directory on your Google drive account by adding the service account email address to the directory like you would any other user.
OAuth 2.0 Credentials as a service.
As you know from the last post in this series Google Developer Console OAuth2 credentials when a user grants you access to there data a refresh token is returned. If you save this refresh token you can use it at anytime to access their data.
Google Analytics email
A user authenticates your application giving you permission to see there Google Analytics data. At midnight every night you could use the refresh token you saved and access there Google Analytics data. You could generate a nice PDF file for them of the stats from the day before and email it to them. Accessing Google Analytics could all be done in a background process on the server so in a way this is a way of automating access to Google Analytics in a background process.
The difference between OAuth 2.0 credentials and Service account Credentials
The main difference is how we got authentication. Service accounts are pre-authorized. I can take the service account email address and add it as a user on my Google calendar and it will have access to that calendar, I can add the email address as a user on a fold on my Google drive it will have access, I can add it as a user on my Google Analytics account it will have access. By adding the service account as a user on the different systems you are pre-authorizing its access to the data. Also service account authentication never has to be refreshed as long as you don’t delete the pre-authorization authorization will work forever.
With OAuth 2.0 a user has to manually authenticate the access using the consent screen. Oauth 2.0 consent is not permanent a user can decide at anytime to remove your access. Access is granted using the refresh token and so has to be refreshed once every hour.
Service accounts don’t work with every Google system. I know from personal experience that they don’t work with YouTube , and blogger. If anyone has a list of other Google systems that don’t support service accounts please let me know so I can add them to the list.
Creating Service account credentials
In the Google Developers console under APIs & auths menu you will find the credentials screen. From credentials screen click the Add credentials button. You will have a choice as to which type of credential you would like to create. Select service account
As it says Service accounts – Enables server-to-server, app-level authentication using robot accounts. for use with Google Cloud APIs.
No before you panic its not just for use with Google Cloud APIs. To my knowledge service accounts work with most of the Google APIs the only ones I have found that it doesn’t work with are Blogger and YouTube APIs.
In the next window you have the option of downloading the key pair that identifies the service account. Its up to you which option you choose I personally only have experience with P12 files. Think of them as the key that opens the door to Googles data, without this file you can’t get access.
That’s it we are done, there is no magic in creating a service account on Google Developers console it is all created for you in three clicks.
Notasecret is used in some of the client libraries to authenticate, it literally isn’t a secret because every service account you create will have this same text.
Service account created
Once you have click OK your new service account has been created.
It is very important to keep these keys secret and secure. Do not posted it to open source projects, do not share it with other users, do not release it in your code if a user could view the source and see it. This includes PHP projects such as WordPress plugins, you will have to tell your user how to create their own service account.
The important thing to remember about it is:
- Asking developers to make reasonable efforts to keep their private keys private and not embed them in open source projects.
You can read my post about my discussion with the author of the change in the Terms of service about how this will affect open source projects. Changes to the Google API terms of service.
I don’t think there would be anything wrong with giving a user your service account email address and asking them to grant you permissions. However if you give more the one user the same service account email address it will be up to you to ensure that each user is only able to see their data and not data owned by another user.
You should now understand what a service account is and have an idea of when you might want to use one.
This concludes my Beginning Google development series. If you have read all the way though this series you should be on the right path to becoming a Google developer. You should understand how to create a project on Google developers console, how to add APIs to the project and how important it is to keep track of your quota usage. You should also understand the difference between public and private data, and how to create credentials to access both public and private data.
Welcome to the Google development family I hope this series has helped you get started.