Sandcastle login

[jjspace]

Description

Initial PR implementing basic ion oauth login flow. This PR includes

• ion oauth login + logout button
• Username and avatar shown when logged in
• Adds the user's default access token to new sandcastles by default
  • (Currently only works when clicking the new + in the sidebar but working on getting the default page load hooked up)

TODO:

• Default page load should load the access token when logged in
• Fix up configuration for multiple client ids in multiple environments (needed for multiple redirect urls)
• Extend the redirect codepath to return users to the sandcastle they were previously viewing

Issue number and link

No issue

Testing plan

• currently only works for the version run from the sandcastle package npm run dev
• Load sandcastle and click Login in the top right
• Login on the ion oauth page
• Make sure redirect works back to sandcastle
• Click + on the left and make sure it loads your access token and works
• Click your username in the top right and log out
• Try with team accounts too

Author checklist

• I have submitted a Contributor License Agreement
• I have added my name to CONTRIBUTORS.md
• I have updated CHANGES.md with a short summary of my change
• I have added or updated unit tests to ensure consistent code coverage
• I have updated the inline documentation, and included code examples where relevant
• I have performed a self-review of my code

[github-actions]

Thank you for the pull request, @jjspace!

✅ We can confirm we have a CLA on file for you.

[jjspace]

@ggetz this wont work in CI until I extend the build to provide a different client id but you should be able to test it locally. There's some code cleanup and separation that still needs to happen with the components and a list of TODOs above but the core is working.

[ggetz]

Thanks @jjspace! Do you mind providing some background on the decisions around token storage, PKCE, etc? Since Sandcastle allows running arbitrary JS code, we need to make sure we're following all best practices with regards to security.

[jjspace]

I think continuing to run serverless there may only be a limited amount of options available to us for the token.

As you mention the primary concern seems to be running sandcastle code that someone else provided that can access local storage, extract your oauth token and send it somewhere for someone else to use. Depending what scopes that has it could expose a lot of your ion info.

The ideal solution sounds like it would be relying on and taking advantage of cookies which are inherently limited by domain. This would probably work great for us since sandcastle.cesium.com and ci-builds.cesium.com are both on cesium.com already and share the logic with ion. However this falls apart if we want to run locally unless we also set up an etc.hosts file to use a non-localhost url.

Another option is to limit the ability to run sandcastles loaded with a code url to make sure you "trust" it before running. This shifts the responsibility to the user to make sure they're not running code that may be malicious. However this could be a very annoying from a UX perspective. We also intentionally try to target users that are newer or non-tech savvy and may just click "run" regardless of understanding. Not really a workable solution
We may want to consider doing a hybrid approach where it provides the "run" check locally and relies on cookies in CI and deployed environments?

I'm also going to look more into the security capabilities of iframes again. I know there are ways to further restrict what scripts running inside them can modify but I don't know if it's possible to prevent them from accessing localstorage for the containing application. It may not be possible with the current setup.
We also need to think about the standalone page which currently doesn't run in an iframe at all but is still on the same domain....