Skip to content

What kind of authentication persistence should we use #15

@richford

Description

@richford

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions