Implement Magic Link Auth

[mbklein]

Steps to Test

1. make deps
2. Add the following to env.json:

   "MAGIC_LINK_EMAIL_TEMPLATE": "dev-environment-magic-link-template",
   

3. make serve
4. To make sure NUSSO auth still works:

• /auth/login?goto=/auth/whoami
• /auth/logout
• /auth/login/nusso?goto=/auth/whoami

5. To test Magic Link auth:

• /auth/login/magic?email=YOUR_EMAIL&goto=/auth/whoami
• Check your email for the login link

While logged in using either/both methods, try to access some institution-only works and file sets. You should be able to access them when logged in via NUSSO but not via Magic.

Authz for works, file sets, and chat have been updated such that chat can be accessed by any logged in user, but protected works and file sets require a NUSSO login.

Notes

• The /auth/login and /auth/callback routes have been replaced by /auth/{stage}/{provider}, where stage can be either login or callback, and provider can be either nusso or magic. It defaults to nusso for backward compatibility. Routing to the correct handler happens by requiring handlers/auth/${provider}-${stage}.js.
• In order to keep the magic link as compact as possible, it's not a full JWT – it's a cryptographically signed buffer consisting of "email|returnUrl" + [6-byte representation of expiration timestamp].

[bmquinn]

Works great, the email template is awesome! 👏

nusso whoami:

magic link whoami:

[kdid]

Since this is going into staging will we need to do some safe checking on the Next app before merge here?

https://github.com/nulib/dc-nextjs/blob/e1d6751c7bf69e92d883d6cecf5650bdb02784bb/components/Header/Super.tsx#L88

[kdid]

Also, can we go ahead and the provider to the chat metrics like we talked about?

[mbklein]

Since this is going into staging will we need to do some safe checking on the Next app before merge here?

I wondered about this. What if we add a display field to the user token that auth providers are required to populate so the front end has fewer decisions to make? No safe checking or ||-ing down a list of fields until it finds one it can display?

[kdid]

I wondered about this. What if we add a display field to the user token that auth providers are required to populate so the front end has fewer decisions to make? No safe checking or ||-ing down a list of fields until it finds one it can display?

I'm fine with whatever

[mbklein]

Works great, the email template is awesome! 👏

It's a direct ripoff of the av-download email template design. 😄