CORB is blocking legitimate requests to Microsoft's OAUTH APIs. |
||||
Issue description
Chrome Version : 70.0.3538.77
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Chrome 70 with --disable-features=CrossSiteDocumentBlockingAlways,CrossSiteDocumentBlockingIfIsolating: OK
Firefox: OK
Edge:
What steps will reproduce the problem?
(1) Start an OIDC authentication with https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/authorize
(2) Request an access token from https://login.microsoftonline.com/{tenant_id}/oauth2/v2.0/token
What is the expected result?
The response should not be blocked, the javascript code should get it.
What happens instead?
The javascript code doesn't get the reply, a CORB error is shown in the console.
Please provide any additional information below. Attach a screenshot if
possible.
Response headers (when trying on firefox) :
Cache-Control no-cache, no-store
Content-Length 2965
Content-Type application/json; charset=utf-8
Date Tue, 30 Oct 2018 23:06:07 GMT
Expires -1
P3P CP="DSP CUR OTPi IND OTRi ONL FIN"
Pragma no-cache
Server Microsoft-IIS/10.0
Set-Cookie x-ms-gateway-slice=005; path=/; secure; HttpOnly
Set-Cookie stsservicecookie=ests; path=/; secure; HttpOnly
Strict-Transport-Security max-age=31536000; includeSubDomains
X-Content-Type-Options nosniff
x-ms-request-id b39af1b1-623b-4845-a488-d13db5070300
Body (removed the access tokens):
{"token_type":"Bearer","scope":"openid profile email https://graph.microsoft.com/Mail.Read https://graph.microsoft.com/User.Read","expires_in":3599,"ext_expires_in":0,"access_token":...}
,
Oct 31
As per comment #1, requesting reporter to share the CORB error from DevTools console? What origin initiates the cross-origin request?. Adding Needs-Feedback label to it. Thanks..!
,
Oct 31
Sorry I don't have a public repro:
- On the microsoft side you need account on Azure cloud (the {tenant_id} part).
- I am not ready to make my code public.
From devtool console:
helper.js:23 Cross-Origin Read Blocking (CORB) blocked cross-origin response https://login.microsoftonline.com/d2be1f11-8ca5-4aa4-9c72-bb93a062ea80/oauth2/v2.0/token with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.
requestTokens @ helper.js:23
(anonymous) @ oidc_return:4
The origin was: https://loas-apps-drive-cmk-test.appspot.com
,
Oct 31
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 31
I've followed-up offline and: - fetch in no-cors mode is used. AFAIU this implies that the response is "opaque" (i.e. response body is not exposed to javascript; it might still show-up in network debugging tools, but javascript that initiated the request will not be able to see the access token). - lbaudoin@ will try to verify if the reponse is also "opaque" in Firefox. If this is the case, then the current bug can be closed as WontFix (although we might still want to discuss whether the CORB error in DevTools console can/should be suppressed in case of "opaque" responses - maybe OOR-CORS helps here by making response body's length 0 *before* CORB starts its processing?).
,
Oct 31
Closing the bug, I misunderstood how 'no-cors' works. The remaining issue is that I couldn't see the reply in the developer tools but that is addressed in a different bug. |
||||
►
Sign in to add a comment |
||||
Comment 1 by lukasza@chromium.org
, Oct 30Thank you very much for reporting the bug. Are there public repro steps? (e.g. what {tenant_id} should I use) Can you please share the CORB error from DevTools console? What origin initiates the cross-origin request? Can you please confirm that in Firefox the response (i.e. the json body) is disclosed to an origin other than the origin the response is coming from? I am surprised that this is allowed without CORS (if this scenario didn't work in Firefox, I would expect this to be a bug in the OAuth provider which normally should have included CORS response headers [like access-control-allow-origin] to allow the response to be seen cross-origin).