Google Apps has been designed from the start to ensure that only authorized processes and people have access to its resources. One of its key strengths—letting users access data from anywhere using any device—is also a potential weakness. This is not something that VBA is too concerned with, because local Office relies on Windows file and user protection and the files likely reside on a desktop or private network.
Apps takes a multilayered approach to security, with user-based identification tied to individuals by Google authentication, and role-based protection defined by permissions. Conversely, resources belonging to individual users are protected from unwelcome script access, as scripts require users to have explicit authorization to access private resources defined by scope.
Figure 15-1 shows how authentication and permission combine to grant a user authorization to access and operate on a resource in an agreed-upon way.
When a user first attempts to access an Apps resource, they first need to provide proof of who they are. Like many providers, Google uses an authentication process called OAuth 2.0. This process, shown in Figure 15-2, is analogous to logging in, except that credential management is delegated to an identity provider (Google), and the authentication process is multistage, verified through the passing of tokens.
Coming to grips with the authentication process is often one of the most challenging tasks for those ...