3

There is a marketplace requirement that if a Google Apps for Work domain admin installs our app for their domain, the admin and any users from their domain should thereafter not see a scope auth screen when accessing our app. The act of installing the app for the domain should implicitly delegate domain-wide authority for the service account associated with our app.

In order to achieve this behavior, I am trying to do delegation of authority to a service account to work on behalf of, AKA impersonate, the currently logged in user.

The code snippet below shows the various attempts that I've made to get this to work. The only one that does work is to pass a domain superuser's email address as the "sub" param (AKA prn) when creating the JWT. However, this essentially elevates a regular run of the mill domain user's privileges to those of super user which is not the desired effect.

var client = new googleapis.auth.JWT(
    '<serviceaccount>@developer.gserviceaccount.com',
    'localhost.pem',
    null,
    ["https://www.googleapis.com/auth/admin.directory.user.readonly"],
    //  null - // 403 not auth
    // {'userId' : 'domainsuperuser@email.com'} // 403 not auth
    // {'userId' : 'me'} // 403 not auth
    // "domainsuperuser@email.com" // works!
    // "{domainsuperuser@email.com}" // not a valid email error
    // 'me' // invalid impersonation prn email address
  );

Does Google honor any other ID than just the email address of the person you want to impersonate such as the special 'me' value?

It feels like we are running into a chicken and egg problem here. Essentially we don't want to hardcode the email address (especially not an admin email), so it feels like we have to make an API call. But we can't make an API call without impersonating a user.

Chris Beiter
  • 117
  • 1
  • 10

1 Answers1

1

You don't need to use a service account and domain-wide delegation in this case. Instead, simply go through the normal OAuth2 flow with the user, and the approval screen will be skipped automatically.

When the admin installs the app and approves your scopes, they are essentially automatically granting you access to those scopes for all users in the domain. And while it is a requirement that users not see the approval screen, you still have to go through the OAuth2 flow with them in order get the OAuth2 token. If you launch an OAuth2 flow for the user, and don't request any scopes not already approved by the domain admin and don't set approval_prompt=force in the URL, then the OAuth2 approval screen will instantly redirect to your redirect URI, making the process invisible to the user.

Eric Koleda
  • 12,420
  • 1
  • 33
  • 51
  • Hi Eric, thanks for the response. This would work for new installations of our app, but any existing installations would need the admin of the Google org to manually add those scopes. Is there a way for them to add scopes to an existing API client's access? Tried it here but it fails when I try to update it: https://admin.google.com/AdminHome?chromeless=1#OGX:ManageOauthClients – Chris Beiter Oct 23 '14 at 21:07
  • Doing the delegation of authority for the domain was the only way we could think of to eliminate the scope prompts for our existing users. – Chris Beiter Oct 23 '14 at 22:40
  • Increasing the scopes your app uses for isn't the most pleasant experience today. Once you update your Apps Marketplace configuration with the new scopes the admin should see the option in the Admin Console to re-authorize your application (they shouldn't need to add scopes manually). However, until they do that users will see an authorization prompt asking for the new scopes. This is normal however, and shouldn't influence your existing listing. It's usually a good idea however to either send an email to the admins or show a warning bar in the app notifying them of the need to re-auth. – Eric Koleda Oct 23 '14 at 23:59
  • Thanks again Eric. I think we have most of the scopes sorted out, but now instead of scopes screen we see this new (to us) screen with a people picker. Is this expected also? [Admin approved screen](http://cbeiter.github.io/adminapproved.png) – Chris Beiter Oct 24 '14 at 17:20
  • Are you using multi-login? If so, that may be displayed the first time. – Eric Koleda Oct 24 '14 at 17:54
  • Do you mean multi-login to [Chrome using profiles](https://support.google.com/accounts/answer/1721977?hl=en)? Yes, I am, but I have tried this also from Safari, Firefox and in private windows, and get the same prompt. – Chris Beiter Oct 24 '14 at 18:20
  • Strange. Can you post a sanitized version of the OAuth2 authorization URL you are redirecting them to? – Eric Koleda Oct 24 '14 at 20:38
  • Hi again Eric, here's an auth URL from our local environments. https://accounts.google.com/o/oauth2/auth?scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email%20https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.profile&response_type=code&client_id=.apps.googleusercontent.com&redirect_uri=http%3A%2F%2F – Chris Beiter Oct 27 '14 at 19:30
  • Everything looks normal. Do you get that screen on every login, or just the first one? – Eric Koleda Oct 28 '14 at 20:22
  • We only get that screen on first login when being authenticated by our app code. However, after the user clicks on the people picker and Google sends them back to our app with the necessary tokens, we redirect the user over to our private auth service, which is supposed to pick up the auth token we already got from Google. But for some reason, it is not finding it, so it does *another* redirect back to google. It's this second redirect that's causing the people picker screen to continue to show up. So I think at this point, it's my problem to figure out. – Chris Beiter Oct 29 '14 at 19:31
  • Hey Eric, just a quick follow up... your advice on this other thread seems to be the fix we needed to eliminate the "admin approved" screen. http://stackoverflow.com/questions/25601007/google-drive-integration-open-with-always-prompts-your-domain-administrator – Chris Beiter Jan 16 '15 at 23:43