When a user connects to an application that uses OAuth 2 authentication, they are presented with a consent screen that describes what information about their account will be shared with the application and it may also includes a list of various Google APIs that the application has requested access to.

Google’s authorization server provides an access token to the application that they can pass to Google with all future requests to authenticate the request.

However in some cases, you may want to build a server-side application that connects directly to Google services without the involvement of the end-user. That’s where Service Accounts come into the picture.

Service Accounts are pre-authorized meaning the user has already granted access to a service account to access Google services on their behalf. The application then uses the service account credentials to connects to Google APIs removing the user from the equation.

The service account acts sort of virtual user and they have an email address so you can share your Google Calendar, Google Drive folders and other resources with a service account. If you are building a web app that uses Google Drive APIs for converting documents from one format to another, service accounts may be an option as the user would not be required to grant access to their own Google Drive for converting files.

Service Accounts with OAuth also support user impersonation and this is particularly useful for Google Apps admins that can build apps to access data of any user in the Google Apps domain. For instance, the Google Apps admin can use service accounts to audit shared files of all users in the organization.

In the next section, we’ll look at the step to create a service account inside the Google Developer console.