Access Management of End User Data - End User Permission Tickets

Question

I have been familiarizing myself with Googles Security Design Whitepaper. As far as I can understand, and with respect to a Micro-services architecture, from the Access Management of End User Data section, Googles authentication scheme works as follows:

1. User authenticates with the "Central User Identity Service" and is issued a session token. This token is associated with the user and stored by the identity service.
2. User attempts to access a Google Service, (e.g. Gmail), provides there session token (usually as a cookie).
3. Gmail passes the users session token onto the "Central User Identity Service" who lookup up the validity of the session token & grants a "end user permission ticket". This appears to be a signed claims based token for the Gmail service to pass around to other services. This is probably a signed JSON Web token or similar, stating gmail has my authority to access users data. This signature can be validated without ever communicating with the Central User Identity Service based on a shared secret, I guess in this instance Google is using a public/private key pair for signature?

Is the "Central User Identity Service" really a central, single instance, sharing a single backing store? It seems so given the architecture and name. How can this be given it represents a single point of failure for Google? Am I missing something?

I am poised to believe that the "Central User Identity Service" may in fact be several sharded instances?

This pattern seems to cause a lot of chatter between the Gmail Service and the Central User Identity Service, meaning that it would need to be involved with nearly every request. Assuming that load balancing is non-sticky the users request to load page #2 of there inbox is more likely than not to hit another Gmail Service instance. Local caching of the users Session cookie's validity probably represents a risk that it would still be honored after revocation?

Is there any public documentation, or anyone that can give me an insight into just how central the "Central User Identity Service" really is?

Answer 1

Is the "Central User Identity Service" really a central, single instance, sharing a single backing store?

What gives you the impression that "Central User Identity Service" means a single instance? "Central" in this authentication scheme means that all services talk to the central service (not necessarily the same machine). Google will have chosen a sufficiently redundant and scalable architecture for this service. "Service" is an abstract term that isn't coupled to any particular deployment strategy or architecture.

How can this be given it represents a single point of failure for Google?

Yes, the service is a single point of failure, but no single machine is a point of failure for the service. Google has likely deployed instances in regions all over the globe to help prevent such a critical service from being unavailable.

I'm not familiar with Google's authentication system, but I've deployed and used Central Authentication Service (CAS) before, and the authentication protocol is very similar to the one you describe. CAS is itself horizontally scalable, and allows you to plug the service into several storage backends--which allows you to choose a storage backend that is also scalable.

I am poised to believe that the "Central User Identity Service" may in fact be several sharded instances?

Sharding is one method of horizontally scaling a system, but it's not the only way. There could be a bunch of replicas of the entire dataset for example.

This pattern seems to cause a lot of chatter between the Gmail Service and the Central User Identity Service, meaning that it would need to be involved with nearly every request. Assuming that load balancing is non-sticky the users request to load page #2 of there inbox is more likely than not to hit another Gmail Service instance. Local caching of the users Session cookie's validity probably represents a risk that it would still be honored after revocation?

With CAS, the Gmail Service would only talk to CAS when a user that does not have an authenticated session with Gmail but has received a session token for Gmail from CAS. In other words Gmail only talks to CAS once to verify the session token. After verifying the session token, Gmail must create an authenticated session for the end user. See this sequence diagram and notice that second requests hit Gmail's session and Gmail doesn't talk to CAS.

a risk that it would still be honored after revocation?

In CAS each service is registered with CAS, and when the user signs out of CAS, CAS sends a signal to each registered service so they can take the opportunity to delete the user's authenticated session.