Able to reproduce the issue on Windows 7, Mac 10.12.6 & ubuntu 14.04 using chrome reported version-62.0.3172.0   & stable-60.0.3112.78 as per the above provided extension file.

Observed 'prompt for choosing an account' eve after user signed into chrome already.Same issue observed from M60 builds. Observed error while loading extension on the earlier build of M60. Hence marking this issue as 'Untriaged' to get more inputs from dev.

Please find the attached screenshot (error screen) & screencast of the issue for reference.

Thanks..!!

Deleted: Win-M59-750617.PNG 194 KB

	Win-M59-750617.PNG 194 KB View Download

Deleted: 750617.mp4 764 KB

	750617.mp4 764 KB View Download

@jmukthavaram I'm attaching the extension without the "minimum_chrome_version" key in the manifest.json file (for allowing installation of this extension in Chrome<60) now, so devs can test this extension out on earlier versions of Chrome.

Deleted: chrome-identity-extension-updated.zip 1.9 KB

chrome-identity-extension-updated.zip 1.9 KB Download

Triage as per the feedback in #3 and find regression if possible.

Really need this bug fixed ASAP! - There are school districts with 100,000+ students waiting on a fix.

Looping to folks involved based on an old regression Issue 621542.
Meanwhile TE can provide regression if reproducible

tomasko126@,

Thanks for the reply.

Now we are able to reproduce the issue in the earlier versions of M60 & observed the same issue from M45 to latest Canary-62.0.3173.0.Hence keeping it in Untriaged to get more inputs from dev.
Please find the attached screencast for reference.

Deleted: 750617.mp4 1.5 MB

	750617.mp4 1.5 MB View Download

@chromium team,

Thank you for reacting so quickly on this. Your work is greatly appreciated.

Nick

identity api -> msarda@ for triage.

Friendly ping to get an update on this issue.

Following up on a...@chromium.org's ping for an update. As mentioned before, we have multiple schools with 100,000+ students that are expecting this extremely useful feature of Chrome to help students use our service.

Thank you very much, and let us know anyway we can help expedite this.

We are branching in few days. Please have a fix ASAP.

msarda@ can we have the latest update on this issue.

I think this is simply how the Google authentication server works. Note that even if the user is signed in to Chrome, the user still needs to grant permissions to the extension via the OAuth 2.0 consent flow. I think that even if you have an account, the user has the choice of adding one as part of the OAuth 2.0 flow.

Did this ever work differently? Is this a regression? Why is the priority of this bug P1 and a RBB bug (I think the OAuth 2.0 flow is functional, or I am misunderstanding something here)?

I will let one of our developers correct me if wrong, but according to your documentation here (https://developer.chrome.com/extensions/app_identity#getAuthToken-prompts), when you invoke the api in silent mode, there should be "no user gesture involved".

The value of this, is to roll out Stackup (or another education extension) without students needing to click anything. It is nearly impossible to get a whole school of thousands of students from 1st grade up to click the right button or not X out. Of course, this only applies when the extension has been pushed out by a school administrator in the Google Admin panel.

We have multiple School Districts that are waiting on this, expecting it to work this way.

Thanks in advance,
Nick G
CEO
Stackup

I am really confused now. In the background.js file in the extension that you uploaded above, you are using "interactive: true", so this is not in "silent mode".

Note that user does need to grant the app permissions to use the Google account that is in Chrome (this is part of the OAuth2 2.0 flow that Google uses for authentication). This is a security requirement of the Google authentication stack and it cannot be bypassed in Chrome as otherwise any app that is installed in Chrome would have full access to the Google account of the user. So you will need to present the consent screen at least once to the user (using interactive mode). Our recommendation is to present it at a convenient time (when the app is installed for example, on Chrome start-up, when the user clicks the app button etc) to avoid this dialog popping up when the user is just navigating the web. 
To understand more about how OAuth 2.0 works, please check out https://developers.google.com/identity/protocols/OAuth2UserAgent

I checked internally with the Google authentication team and the current flow is Working as Intended. I will close this bug as Won't fix as it is working as intended.

@msarda: Does this also apply to an extension force-installed via Google Admin console?

Per https://support.google.com/chrome/a/answer/6306504?hl=en:
“Force-installing an app or extension *gives it permission to access information on the device it's installed on*. For example, an app might access a user's bookmarks or use their location. It can also access a device’s Directory API ID through an extension API. And it can use the Chrome enterprise.platformKey API without requesting permission.” -> Does this also apply to chrome.idemtity API?

Also per https://stackoverflow.com/questions/44854111/is-it-possible-to-skip-oauth2-consent-screen-when-using-chrome-identity-api/44856192#44856192 :
“If you include identity.email in the manifest permissions, and it is a force-installed extension or app through the admin console, then you will be able to get the user's identity and also the auth token without user oauth prompt approval.

However this only allows you to get the user's identity, no extended permissions. Any extended permissions (such as gdrive access, etc) need an oauth prompt.”.

Is the above statement correct?

Thank you for your answers.
TT

You are mixing 2 things here:
1. From your quote: "“Force-installing an app or extension *gives it permission to access information on the device it's installed on*". Access to the Google account (via Google public APIs) is not "information on the device". So, in my understanding, this does not apply to fetching auth tokens.
2. Permission to identity.email grants you access to profile information via a call to chrome.identity.getProfileUserInfo as documented here https://developer.chrome.com/apps/identity. Access tokens are guarded by OAuth consent.

This is basic security - you cannot simply force install an extension on a device and have full access to the Google account without any user consent.

I do not understand what you are trying to do here. The only explanation so far from you and from Nick G (CEO of Stackup) is that you have 100.000+ users that are waiting for this, but that does not explain the product you are building and how you want to use the chrome.identity API. Why do you need access to Google APIs? What Google APIs do you need to use? What is your security model if you want to bypass OAuth consent? Could you please also elaborate why you want to avoid having user consent access to their account (the profile information is available without any consent via a call to https://developer.chrome.com/apps/identity if you have identity.email permissions)?

Msarda,

Thank you for listening, and for your questions - I am happy to elaborate on who we are, and what we do. Our company and product is built around Chrome, so we take your time and efforts very seriously.

Stackup is a Chrome extension that tracks, measure, and reports online reading. We are an education tool that allows students to get credit for what they read online. We have categorized the web’s articles by subject area and grade level. Students have been forced to read uninteresting content, and then take reading quizzes, and we have fixed that by unlocking the learning benefits of the web and using our tech. to track reading time online. The outcome is students read more, and educators can measure progress. You can learn more at Stackup.net.

Below is what we have today and what we are trying to accomplish:

Today:
A school district using the Google Admin panel pushes the Stackup extension out as a force installed extension. When a student signs into any device (Usually a Chromebook) using their Google log in, it knows to serve them the extension (so on a Chromebook, the extension is tied to the user, not the device). However, every student still needs to click on our extension, and sign in using Google SSO. This works great on a classroom by classroom bases, and we are very lucky to have this feature in Chrome.

However, there are schools that want to deploy the Stackup extension district wide to capture reading & online engagement across students. Now getting every student to click the extension, and sign into Google becomes an impossible task. Some of these districts have 200,000 students, and over 5,000 teachers. Trying to coordinate 5,000 teachers and 200,000 students to sign into Google so the district can capture reading and online engagement data is very hard.

What we are trying to accomplish:
Students/users that fall under the Organizational Units (OA’s) of the school district Admin, where the school district admin has force installed an unlisted version of Stackup, not only get the extension served to them (like it can do today), but can also identify them without user gesture. This way, a school district does not have to interrupt 5,000 classrooms to receive online reading data on a student.

The school district will have already given Stackup every students name and email address and they will already have a Stackup account. The bottom line is we just need to know which student is using what extension, by their email address, so we can give the reading time to the right student (or signed in user).

Thank you in advance for your responsiveness and diligence. I am happy to provide more information. We are truly only trying to do good in education and make Chrome an even more powerful tool than it already is. I thought we understood your documentation correctly before we started building and offering this feature. Perhaps we missed something, or there is another approach.

Thank you for the explanation.

1. If you only need the email address on the client, you can simply use chrome.identity.getProfileUserInfo that provides this info without any OAuth 2 consent screen.

2. If you need to use an access code, then please read below:

2.1. It would be good to understand what Google API you want to use (otherwise, why would you need an access token?).

2.2. Just to make this clear, the students are expected to sign in to Google with an account that is on a domain that is managed by the school, right? This is how the extension is pushed from the server on Chrome once the user signs in to Chrome, right?
- If the students are using a regular <yyy>@gmail.com account to sign in to Chrome, then this is game over (you cannot bypass the OAuth 2 consent screen).
- If the students are using an account that belongs to the school (e.g. yyy@myschool.com), then the admin of the domain may be able to configure to bypass the OAuth 2 consent screen for some Google APIs (you need to know which ones you want to use). I do not know how to do this though (I'll try asking this internally, but I cannot promise a quick answer on this). You could start by looking at the Google admin console for that domain. Maybe try looking around for this option in there.

Of course!

The email address should work for us and our customers, it is just a little less seamless and not as secure as confirming our systems via OAuth token.

We are absolutely NOT trying to accomplish this with regular <yyy>@gmail.com accounts. Strictly yyy@myschool.com accounts were we have contracted with the school to provide Stackup, and the Google accounts are owned and run by the schools admin(and usually the devices are too). -- Per the report of this problem, everything already works with our system perfectly, except for the account chooser that pops up. We thought this was a bug since it wasn't an allow/permission popup, just an account chooser, and we thought this could be done without any UI gesture when forced installed via admin on admin owned/run accounts.

Any insight would be greatly appreciated.

Thanks for listening,
Nick