# Zoom.us cookie causing OAuth authorization issues

**URL:** <https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888>\
**Category:** API and Webhooks\
**Created:** [August 12, 2020, 12:10am UTC](https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888 "2020-08-12T00:10:18Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![edu\_dev4](https://avatars.discourse-cdn.com/v4/letter/e/ad7895/32.png) [@edu\_dev4](https://devforum.zoom.us/u/edu_dev4)\
**Post date:** [August 12, 2020, 12:10am UTC](https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888/1 "2020-08-12T00:10:18Z")

</div>

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](http://zoom.us) site maintains a cookie that remembers the first user. Even if the first user manually logs out from [zoom.us](http://zoom.us), that cookie remains.

In this situation, if the second teacher begins the authentication process, the [zoom.us](http://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](http://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.

---

<div class="post-metadata">

**Author:** ![tommy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tommy/32/72769_2.png) [@tommy](https://devforum.zoom.us/u/tommy)\
**Post date:** [August 12, 2020, 6:37am UTC](https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888/2 "2020-08-12T06:37:23Z")

</div>

Hey @edu_dev4,

Is this about [Zoom Developer OAuth](https://marketplace.zoom.us/docs/guides/auth/oauth) or how authentication works on [zoom.us](http://zoom.us)?

If [zoom.us](http://zoom.us), please reach out to [support.zoom.us](http://support.zoom.us).

Thanks,  
Tommy

---

<div class="post-metadata">

**Author:** ![edu\_dev4](https://avatars.discourse-cdn.com/v4/letter/e/ad7895/32.png) [@edu\_dev4](https://devforum.zoom.us/u/edu_dev4)\
**Post date:** [August 12, 2020, 3:12pm UTC](https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888/3 "2020-08-12T15:12:44Z")

</div>

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](http://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](http://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.

---

<div class="post-metadata">

**Author:** ![tommy](https://sea2.discourse-cdn.com/flex016/user_avatar/devforum.zoom.us/tommy/32/72769_2.png) [@tommy](https://devforum.zoom.us/u/tommy)\
**Post date:** [August 12, 2020, 6:27pm UTC](https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888/4 "2020-08-12T18:27:13Z")

</div>

Hey @edu_dev4,

Well glad to hear it’s working! 🙂

If you have additional issues with this, please reach out to [support.zoom.us](http://support.zoom.us).

Thanks,  
Tommy

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex016/uploads/zoomdeveloper/original/3X/6/1/614bdd549b610bbaa46ff934617683a02bdaa03c.png) [@system](https://devforum.zoom.us/u/system)\
**Post date:** [September 12, 2020, 4:27am UTC](https://devforum.zoom.us/t/zoom-us-cookie-causing-oauth-authorization-issues/26888/5 "2020-09-12T04:27:27Z")

</div>

Closed on September 12, 2020, 4:27am UTC

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