Zoom.us cookie causing OAuth authorization issues

It is very common for teachers to share a login within a SIS application (seating chart, grade book, in our case Zoom integration). The easiest example is when a teacher is out at the beginning of the school year, and the year begins with a substitute teacher.

When a teacher authenticates through Zoom, we keep their refresh_token so they only have to auth once. Sometimes they may need to auth again, under some circumstances, but ideally only once. In the above situation, when the teacher was not the first to make that connection, we offer the ability to essentially invalidate the refresh_token so they can start fresh. This works, mostly.

Where it doesn’t work is the frustrating part. If they happened to share a computer, and both love the same browser, the zoom.us site maintains a cookie that remembers the first user. Even if the first user manually logs out from zoom.us, that cookie remains.

In this situation, if the second teacher begins the authentication process, the zoom.us cookie, even if the first user logged out, still remembers that first user. It then skips the authentication process, re-authenticating the first user.

I don’t really care so much about the alarming security issue there. I am more concerned about these teachers not being able to authenticate. Sure, there are two workarounds:

  1. Clear browser cookies - This is an annoying process for users
  2. Use a different browser, or a fresh incognito window.

For now we are going with #1. But really, if a user logs out of zoom.us, it shouldn’t maintain a cookie that allows authentication to be skipped even if the user is logged out.

I am looking for other ways to get around this, but figured I’d raise the flag.

Hey @edu_dev4,

Is this about Zoom Developer OAuth or how authentication works on zoom.us?

If zoom.us, please reach out to support.zoom.us.

Thanks,
Tommy

Curiously, today it is behaving properly. Last night if I tried to host a meeting I did not create using the start_url from the API, it would automatically authenticate me as the the creator of that meeting. Then that zoom.us cookie would be set and allow for automatic authentication.

This morning, when I attempt to join using the start_url in the same fashion, it now tells me “If you are the meeting host, sign in to start the meeting”. If I am already fully and intentionally logged in to zoom.us, it tells me that I am not the host and offers to let me join as a participant.

I’ve spent two hours this morning trying to break this the way I did last night, and things look solid.

Hey @edu_dev4,

Well glad to hear it’s working! :slight_smile:

If you have additional issues with this, please reach out to support.zoom.us.

Thanks,
Tommy

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.