How to get access token for User Based Server Application client type
I have to access API, in my case application will be running on auto scheduling without user interventions, after reading https://support.panopto.com/s/article/support-panopto-com-s-article-oauth2-client-setup support link the client type that best suites to my use case is "User Based Server Application" that I have created and now need to get Auth code and access token using a web application, I am referring this support link https://support.panopto.com/s/article/How-to-Get-OAuth2-Access-Tokens-for-Users?t=1600412234437 in this document it is mentioned 'How to get access token' what I understood in link my client type is User Based Server Application which is not covered here, only Server Applications are described than followed that on point number "1.3 Getting a token for Server-Side Web Applications" in this section it is not mentioned how to pass user credentials to get Auth code but for User Based Server Application client type we need to pass user credentials based on nature of application which is mentioned in https://support.panopto.com/s/article/support-panopto-com-s-article-oauth2-client-setup link point 16.c.
Both links are confusing, can anybody suggest what to do in this case.
Answers
Hi Naseer,
Thank you for posting your question.
I hope this document helps you to understand how OAuth2 token may be acquired by a service.
Note that User Based Server Application is not recommended as a best practice of OAuth2, which is mentioned in our support doc already. Please evaluate carefully if that is what you really need before proceeding.
Preface: The challenges to get something working in both the SOAP and REST API were significant and I've spent way too much time editing this to not post something. Hopefully, I removed the unnecessary words of frustration. Hopefully, I've focused on the difficulties we've faced and that I've communicated here. Hopefully, this means that the documentation can be updated to make someone else's experience better.
Sorry to resurface this discussion, but I think that the reason that this question came up in the first place is that the "OAuth2 for Services" and Panopto API credentials documentation in general is very confusing. Compounding that, I found the various types of REST API clients to be very confusing and the existing explanations definitely sent me down the wrong path.
The Server Application type initially seemed like a winner because it did not require a user, but as far as we could tell it doesn't have permission to do anything. I didn't trust the "This type of client is not needed unless specified by Panopto support staff or documentation." statement and now I wish it was far more forceful: "Do not use this type of client unless specified by Panopto support staff or documentation." Maybe if it was the last one in the list, I wouldn't have started with it.
After a few discussions with capable members of this community, the consensus is that the User Based Server Application is the only option for admin-level autonomous operations that can actually do anything. At the same time, it's documented as "not recommended" and "should rarely be used". Yes, we don't want individuals to hand us passwords, but for admin-level service automation, we have the credentials and we just want to use them without logging in to the website.
If this is the wrong approach, please improve the explanations. The response was "evaluate carefully if that is what you really need". I don't see details or tools for how we would evaluate which option is needed. We can't see what is going on behind the scenes and all we get back from the API is a failure message.
Jonathan,
Thank you very much for thoughtful input and I apologize you spent much time to figure it out. We will update our public API documents to reflect your input in the near future.
For the time being, I want to explain a little more for two topics you specifically pointed out.
“Server Application”: This type is usable only with specific API which are designed for the application level permission. As of today, all API belonging to this category are for our hardware partners and nothing is available to the customers.
“User Based Server Application”: This type is usable for all Panopto REST API where the user permission is needed. It is usable as far as you are comfortable to store administrator’s password on your application and pass it directly to Panopto server. We wrote “should be rarely used” because the industry (like IETF) considers this is a legacy approach and less secure than newer approach. As you wrote, this is most likely the only option if you absolutely want to avoid accessing to website.
Note that “Server-side Web Application” is the recommended approach for the service application. It requires a little additional development work (typically integrating a supporting library) and an initial admin operation to access the website and grant the permission. Our latest example uses this. However, once it’s done, the rest works without password or any further admin operation. You may find that many of inter-system services in the world use this. At the same time, Panopto understands that every developer may not afford that additional development, therefore provides “User Based Server Application” method as a fallback.
Hiroshi,
Thank you for your generous response. I really appreciate the time that you took to explain these in more detail.
I'm hopeful that this information might help other users who are integrating Panopto into their enterprise systems.