Handling multiple google signed-in users using oAuth - php

Question

I have this app that uses data from gmail accounts. I have been able to create a php site that retrieves the oAuth tokens (online and offline) and later the necessary user information from the mailbox, all using the Google php api. Now to my problem:
When a secondary user logs into gmail in a browser that was previously used by an authorized user, the credentials seems to "stay". So the 2nd (or 3rd or nth user) can see data non-related to them, which is also a security hole. But most important: every loged in user into gmail is seeing only the data of the 1st logged in user.
The question: Is there a way I can use Google PHP API or Google JavaScript API to retrieve the user name of the current gmail session?
This is the current php piece of code I've been using to retrieve the user data:
use google\appengine\api\users\User;
use google\appengine\api\users\UserService;
session_start();
$user = UserService::getCurrentUser();
$userEmail = htmlspecialchars($user->getEmail());
The idea is that the app uses the current gmail user information to query a database and then retrieve the data for that specific user - and only that logged in user. If the user is not authorized, then prompt for the authorization window and ask for permission.
Any ideas or suggestions are welcome.
UPDATE (Sept 7, 2015):
I have made a change in the app.yaml so every logged in user in gmail gets served a different uri from my app. That works just fine. Now I face a new issue: how can I make the PHPSESSID and SACSID cookies to use an specific path instead of the whole domain? That way - theoretically - I can have several logged in users each and every one connecting to a different subfolder.
I've read the whole documentation about the UserService but it seems all I can do is redirect to this:
UserService::createLoginURL($_SERVER['REQUEST_URI']);
And that takes care of the authentication.
The question: How can I restringe the scope so the cookies gets the appropriate folder path?

Answer 1

The main issue is that once you log in to App Engine (via the UserService), that a user session has now been created in your App Engine application, and therefore it doesn't really matter what you do in GMail or any other Google application, as the session has already been created, and persists within your application.
The App Engine UserService was available way before secondary logins were even possible, and it hasn't been updated since. So this use case probably wasn't a consideration when the API as developed.