Google 2-legged OAuth2 Authorization (service account) in Apache Camel components

The standard Java Mail mechanism (now Jakarta Mail) allows you to easily and conveniently send a e-mail directly from your program. To do this, you only need to keep the username and password for authentication on the mail server in the settings. Username and password in your email client, username and password in every application… If you change (and you need to do this quite often), you need to change the password in the settings of each application. It’s not very convenient and definitely not secure.

The OAuth2 security standard offers the following solution. Each system creates its own “username - password” pair (ClientId - ClientSecret in terms of OAuth2), which the application uses for authentication. The authentication server requests the user (person) permission for each application and, if obtained, issues an application with a temporary token that will be used by the application for further authentication.

The schema is very good and works fine if the application works with the user interactively, processes the data synchronously. How to get out if the user is unavailable? The OAuth2 specification leaves this up to the authentication server.

And Google uses this opportunity in the following way. In the Google Cloud Platform Console, you must create a project, define one or more service accounts for it, and assign permissions to each of them to perform operations. As a result of all these settings, a key file in JSON format with all the necessary details will be generated. This file should be used in the application.

Apache Camel has several components for working with Google services: Sheets, Calendar, GMail, Drive. To support the authentication method proposed by Google, parameters have been added to each of them: keyResource, scopes, delegate.

The KeyResource parameter points to a JSON file with details obtained from the Google Cloud Platform Console. This parameter is optional and if not specified, the standard authorization method by ClientId and ClientSecret will be used.

The Scopes parameter is an enumeration of the Google Scopes that the application will need for correct work. This parameter is optional and if not specified, the widest permissions for this Google service will be requested.

The Delegate parameter requires additional actions in the Google Cloud Platform Console and allows you to perform actions on behalf of other users. Optional parameter.

This completes the description. I hope it helps keep your applications efficient and secure.