Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What kind of authentication persistence should we use #15

Open
richford opened this issue Mar 28, 2023 · 3 comments
Open

What kind of authentication persistence should we use #15

richford opened this issue Mar 28, 2023 · 3 comments
Labels
question Further information is requested

Comments

@richford
Copy link
Contributor

I'm starting this issue to discuss authentication state persistence:

Background information

We can specify what kind of authentication state persistence we want to enforce. Basically, when a user signs into the dashboard, we can choose to do one of the following with their authentication state:

  • indefinitely persist their authentication state until explicit sign out (called "local" persistence)
  • clear their authentication state when the window or tab is closed (called "session" persistence)
  • clear their authentication state on page reload (called "none" or no persistence)

It can be convenient to persist the user's state so that they don't have to explicitly sign in every time they visit the dashboard on the same device. However, given that the dashboard is likely to be used by multiple users on shared devices in schools, I think we don't want to use local persistence.

Short-term decision

In the short term, we should pick one persistence strategy for all users. Should that be "session" or "none?"

Long-term decision

It would be nice to develop a solution in which users in schools had "session" or "none," but users at home had "local" persistence. One way of doing this would be to deploy the dashboard to different subdomains (e.g., schools.roar.com vs. home.roar.com or some such). For the schools subdomain, we could enforce "session" or "none" persistence, while for the home subdomain, we could enforce "local" persistence. There are likely other strategies I haven't thought of.

What do you think?

@richford richford added the question Further information is requested label Mar 28, 2023
@jyeatman
Copy link
Member

Is it easy to switch between these? Long term, it's a nice option to give to schools assuming it is a simple "one liner" to switch. Many schools we work with have one laptop per student. In that case "local" would be really nice. For others, I agree that session probably makes sense.

@ctflores
Copy link

My bank, for instance, gives me a choice. It asks something like, "Is this a personal computer, or will others be using this device?" and it adjusts persistence accordingly. We might do that for the dashboard.

How often does the page auto-reload? I think session should be fine for schools-- does Clever offer any suggested guidance on this?

@ctflores
Copy link

If they're using a single-sign-on option (google or clever), the dashboard would be linked to their log-in there, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants