Understanding OAuth process flow

API and Webhooks Meetings
1

I’m having a hard time understanding the Oauth authentication process flow. I’ve gotten parts of it to work in Postman but I’m not sure I’m getting how this will work in a standalone job.

I’m very familiar with how server-to-server apps work and their authentication, but I have a need for an end user to be able to access their own user account and to be able to schedule meetings on their own behalf. The server-to-server app is not an option since that would give them access to any user, not just their own.

Since I’m doing my testing in Powershell I’m not able to have it handle the redirect URL so for testing purposes I’ve created a web page to receive the rediret and display the code. I’m able to use a browser to hit the Zoom /outh/token API, go through the authentication for the user, and get the authorization code. Then I can use that authorization code to get the access code in my Powershell script. However, using that authorization code only seems to be working one time. Should that authorization code be good over time or do I need to keep generating that each time I get an access token?

Here are the questions I have in trying to understand the process flow.

  1. Is the authorization code good for forever? Or does it need to be generated every time I run a job? Does it expire?
  2. When I get the authorization code it seems that I have to interactively authenticate the user I want to have access to the API. If this is a onetime process that wouldn’t be an issue to initially get the authorization code and just use that in the script. If that has to be done every time I run the job, is there supposed to be a way to automate the user authentication? A way so it doesn’t require the interactive browser auth?

I haven’t found many Powershell examples, and I realize I may be facing some limitations in using that language, but I think if I understand the flow better, I’d have a better understanding of how I need to approach it. The documentation is very vague on a lot of aspects.

2

@jferguson

  1. Is the authorization code good for forever? Or does it need to be generated every time I run a job? Does it expire?

Authorization code is only good for one time use. Once you use it, it will no longer be valid. On the other hand you will now have an access token and refresh token. If my memory serves me well, access token will expire in 1 hour, whereas refresh token will be valid for 90 days.

You can then use the original (or *subsequent) refresh token to get a new (access token + *refresh token).

When I get the authorization code it seems that I have to interactively authenticate the user I want to have access to the API. If this is a onetime process that wouldn’t be an issue to initially get the authorization code and just use that in the script. If that has to be done every time I run the job, is there supposed to be a way to automate the user authentication? A way so it doesn’t require the interactive browser auth?

There are occasions where you might need to reprompt user for access, but most of the time, you can just keep using refresh token (90 days expiry) to get a new access token (1 hour expiry).

If the user is signed in, and has previously already authorized the app, subsequently they will not need to click accept. In fact the the page below won’t be shown again, and will be immediately redirected to the “redirect URL”.

image
image656×1357 89.9 KB

3

Thanks for the information. That helps a lot to understand how I would implement the flow. It wasn’t obvious (to me) that it was the refresh_token that I need to keep track of from run to run. Then either keep track of the new refresh_token between runs or make sure I update it in 90 days.

This has helped a lot to fill in the pieces so I’m ready to start my implementation.

1 Like