SPIKE: Can auth0 be used with Andi UI?

[JulieMaterni]

As a data contributor or curator, I want to have one account to share and view my datasets so that I have an easy to use, streamlined experience.

ACs:

• [ ] How does auth0 play with Andi UI?
• [ ] Can a user have one account that works for both Andi and Discovery UI?
• [ ] Write cards necessary for implementing auth0 for Andi

[bbrewer-forge]

PR that will likely close for using Auth0 along with UberAuth https://github.com/smartcitiesdata/smartcitiesdata/pull/914

Main caveats:

• Auth0's standard app config requires the URLs involved to be both TLS and a fqdn that is not localhost so the example has xip.io hostnames in it
• Client secret has to be provided, which is something we don't have to do for SPA apps

Alternatives:

• I'm 90% certain we can also just do a SPA auth through a LiveView hook, in which case, we wouldn't need TLS, the xip stuff for local or the client secret

[bbrewer-forge]

Main example from Auth0 is here - https://auth0.com/blog/elixir-and-phoenix-tutorial-build-an-authenticated-app/

[bbrewer-forge]

Otherwise, in summary:

• how does it work with ANDI? It works via an auth code, but the more traditional server side way that requires a client secret to be injected (not a huge deal)
• can a user have one account that works with both? yes
• will write cards next week

[bbrewer-forge]

It turns out that the above only handles authentication. As for authorizing each request - we would need to use Guardian still similar to how we do with Disco API

https://hexdocs.pm/ueberauth/Ueberauth.Auth.html#t:t/0

Basically, when we do finish the authentication we can get the JWT from auth_returned_by_auth0.credentials.token and then attach that to the conn via Guardian's standard functions. For a live view, this can then be attached to the socket on view mount so as to be attached as data on the socket. We can then examine the JWT with the key verifier on that socket just like we do with Guardian in Disco API, with the only major difference being that it's not a Plug at that point as LiveView doesn't utilize plugs.

[bbrewer-forge]

The only major gotcha with using Guardian in this case, is that we need to store the JWT in both the LiveView sockets on mount AND in a session cookie (which would be reasonable for a server-side app, but we would want CSRF tokens, at a minimum for this).

[bbrewer-forge]

Looks like our browser (server-side) pipeline is already set up for CSRF via hidden inputs on the forms

https://angelika.me/2019/12/31/csrf-protection-in-phoenix/

We would also need to fix-up our links to be HTML links instead of buttons for some of this to work.

Otherwise, the API itself would just be covered by a required JWT in the header as a Bearer at that point

[bbrewer-forge]

The example PR for this uses the Phoenix Session that we already have, as that meshes very easily with the LiveView mount. https://github.com/smartcitiesdata/smartcitiesdata/pull/914

[bbrewer-forge]

Cards:

• Set up Auth0 for ANDI as "REGULAR WEB APPLICATION" and then minimal wiring of ANDI to this (Ueberauth's auth/auth0 and auth/auth0/callback endpoints) https://auth0.com/blog/elixir-and-phoenix-tutorial-build-an-authenticated-app/ - tech note about an "andi" API/audience in addition to the current discovery_api one
• Force authorization for all pages and views - AC: go to login if not logged in - tech notes about duplication between this and Discovery API - tech notes about LiveView + mount + redundancy
• Do logout - tech note about revoke like in Disco API