Allow notebooks to use OAuth implicit grant flow

I’d like to use OAuth in a notebook (e.g. to use the Spotify Web Playback SDK), but the code running in an iframe is blocked from accessing window.parent.location.hash so it’s not able to read the access token after authorization.

It would also be useful if an iframe could clear window.parent.location.hash after it’s been read, so that the token doesn’t accidentally get shared.

Would it be possible to provide an interface in stdlib that a notebook can use to access the location hash of the parent notebook window?

Alternatively, a helper method that runs in the parent window and handles the whole “Implicit Grant” OAuth flow, returning a token to the iframe, would be amazing :slight_smile:

1 Like

The structure of notebooks is set up to prevent any access of window.parent from a notebook - given that arbitrary code runs in the notebook’s “worker”, it’s essential that that code is sandboxed and prevented from any potential privacy/security risk.

That said, maybe there’s route to getting OAuth into the standard library! Will have to think about that one for a bit.

I’m not familiar with OAuth implicit grant flows, but would adding allow-same-origin to the worker/iframe provide some options here? Quick test with the Google APIs Client Library seems to work with that change and not without it:

Codepen demo

^Note, this example is actually an iframe in an iframe. Codepen provides the outer one (which also sets allow-same-origin).

Found the answer to my question here, explained nicely by Jeremy:

We can’t add allow-same-origin to our sandbox attribute, because it would allow cookies, localStorage and sessionStorage to be shared (or interfered with) across notebooks. They’re all hosted on

That reasoning makes sense to me. I’d love to be able to use Observable with various Google APIs if the sandbox restrictions could be eased at some point in the future. :slightly_smiling_face:

Thinking about this for longer, it perhaps doesn’t make sense for a notebook to handle authentication (and all the security issues that go with that).

I can think of one possible workaround, which is for an external service to handle the OAuth part of things and display a code which the user can then paste into an input in the notebook, allowing temporary access to the API.

I think it would be a pity if we can’t figure out a way to talk to the parent and engage the values of .search and .hash etc. Without that, we cannot have notebooks use OAUTH to engage the user’s own data or even to have notebooks to be parameterized with a link. That is after all one of the main motivations to develop on the web platform. A possible solution might be to have messaging passing set to allow the web worker to do that?

aha, I see now what you mean aeaton, the web worker could open a separate window to handle OAUTH and may be able to get bearer token back.

It seems that allow-same-origin has been added to the worker iframe’s sandbox attribute, so it’s possible to access document.location.

yes and I have some oauth clients here for Google, Reddit, Github, Strava. Note it uses to store the client secret