Developer Authentication

[bradleyDean]

What?
Currently, frontend developers need to authenticate using the production Auth0 account when working on the open-tacos project. This can be inconvenient. I would like to explore options for making the authentication process more straightforward for frontend development while minimizing potential risks to the staging environment. Note that it is not enough to just bypass authentication on the backend, since front end devs might not want to run their own local version of the backend and even if they do, they will still get stuck on the login pop up unless we implement some way to get past it.

How important is this to you?

• Important

Options
(Thanks to @zichongkao, for the suggestions, which I am paraphrasing and extending below)

1. Mocking Auth0: Create an Auth0 connector and mock the connection in dev mode. This would enable us to insert custom JWTs upon login. The work involved would be:

• Create a mock JWT token that simulates a user session in the development environment (I am not sure which start up script we would need to modify, for setting the development environment variable or if an existing script already does this).
• Modify the frontend authentication logic to bypass the actual Auth0 authentication process and use the mock JWT token when the app is running in development mode.

This option would involve modifying the frontend code to implement a mock authentication process, which could introduce additional complexity and maintenance concerns. However, it would allow developers to work on the frontend and backend without needing to interact with the actual Auth0 authentication system.

2. Test Accounts in Auth0: Create a few pre-built test accounts in the development version of Auth0 and share their credentials with developers. (I think this is the best option. This solution keeps the development environment close to the production environment and avoids introducing additional bypass logic in the authentication code.)

To implement this solution, we would need to:

• Create a few pre-built test accounts in the development version of Auth0.
• Share the credentials of these test accounts so that developers can use them for their work.

Benefits of Option 2 over Option 1

Minimizes the differences between the development and production environments.
Avoids cluttering the authentication code with additional mocking logic.
Simplifies the implementation process.

Important Considerations

When implementing this solution, we should address the following concerns:

• Make sure developers are aware of the potential impacts that they can cause using the various dev credentials available to them.
• Limit the permissions of dev accounts to prevent accidental changes to the staging (and of course, production) environment.
• Initially, review and monitor the actions taken by test accounts to ensure their proper usage.

Open Questions

• What combinations of permissions/roles do we want to include in various dev/test accounts?
• How do we share these account credentials? Are some of them publically available in the readme (maybe the read-only accounts) and others have to be requested/approved?

[vnugent]

Currently, frontend developers need to authenticate using the production Auth0 account when working on the open-tacos project. This can be inconvenient.

1. open-tacos Dev & staging both connect to the development instance of Auth0, separate from Production Auth0. You'll need to create a separate log in.
2. Contributors who want to work on UI pages protected by authentication are provided with an additional Auth0 secret key to add to their .local.env.

In development or production you're only required to log in once and Auth0 remembers you for at least 30 days. I'm not 100% clear how developer experience is impacted by this.

[bradleyDean]

Currently, frontend developers need to authenticate using the production Auth0 account when working on the open-tacos project. This can be inconvenient.

1. open-tacos Dev & staging both connect to the development instance of Auth0, separate from Production Auth0. You'll need to create a separate log in.
2. Contributors who want to work on UI pages protected by authentication are provided with an additional Auth0 secret key to add to their .local.env.

In development or production you're only required to log in once and Auth0 remembers you for at least 30 days. I'm not 100% clear how developer experience is impacted by this.

Ah gotcha. I think I know what happened. I saw a comment in response to my backend auth bypass proposal which I interpreted to mean that we have a related issue on the front end.
After reading your comment it is clear that I jumped to a conclusion and should have done more research. Sorry about that.
I'm going to close this issue because it seems like there is no problem with auth on the front end!