API authentication

[begberts]

My organization is migrating to Webex Calling from CUC/CUCM. Previously, I automated most tasks with PowerShell, but I will be migrating things to Python for Webex Calling with the hope of leveraging the wxcadm library. My organization's security team wants to leverage OAuth authentication, but I'm having trouble understanding how to implement it in my scripts. It is my understanding that the technicians running the scripts will need to log into the developer portal to get an authentication token that will then be put in the scripts. 

Is that the only way to handle the authentication or am I missing something?

I'm used to working with Microsoft's Entra API and would love to have an authentication experience like theirs. I simply enter a command to connect to the API, and an authentication window appears where I enter my admin account credentials. The API session is then authenticated, and I don't have to pass any additional information to it. I'd be ok with passing the authentication token each time I make a request but I am hoping to at least have a simplified process of getting the authentication token without the need to log into the developer portal website.

[dtibbe]

The developer portal token is just for testing purposes. If you have an integration for your tasks check out Integration (https://developer.webex.com/docs/integrations) and Service Apps (https://developer.webex.com/docs/service-apps) depending on your use case. Both use OAuth, in both cases you will get an access and a refresh token.

During the authorization flow, a code will be issued to your client which must be extracted. I do not know the Python libraries, but I guess there are helpers as well.

I once registered a local host Uri and hooked the 404 error to get the code in a .net client application..

[begberts]

I did more research on the subject and figured out that my confusion was coming from the Access Token expiration for the Service App. Cisco documentation shows that it expires after 14 days and that we can refresh it with the Refresh Token. But I also read that the Refresh Token expired. To me that made the app registrations pointless. 

It wasn't until this morning I finally found a different community discussion where it was mentioned that the Refresh Token automatically refreshes when it's used. Solved: Re: Access/ Refresh token renewal process - Cisco Community 

I'll reiterate user lionelseydoux's comment that the token documentation in Build - Integrations | Webex for Developers and Build - Service Apps | Webex for Developers should be updated to mention that fact. I feel like I wasted a lot of time trying to figure this out. 

[Thomas Schittli]

That's funny, and exactly why we never use Cisco/Webex APIs if possible:

1. While Amazon, M$, etc. offer practical, working code examples in PowerShell, bash, etc.,
2. with Cisco you have to try to figure out how anything works reliably in everyday life using Google, AI, the community, docs, etc.

That's why we have dozens (if not hundreds) of M$ API integrations,
but only one Cisco API integration

Cisco usability is just nonexistent.

Kind regards,
Thomas

[Ashton Jordan]

@begberts I'm sorry that you wasted a lot of time seeking the information you needed for how the refresh token works. And looking over at the other thread, I see that @sandiban did mention that he would follow up on seeing how we can get that update completed. I'll follow up with him personally, to see what happened on the follow up. If all else fails, I'll personally see to it that we add better verbiage to state how the Refresh Token works within our Token flow. 

@Thomas Schittli Thanks for the feedback on your experience with our Developer API's. And also sharing that you find it easier to develop using API's from AWS, Microsoft, etc. I'm generally interested in an elaborated version of what you have shared here, and on the other thread if you would be willing. I've sent you my booking link, so that you can grab some time on my calendar for us to chat if you are willing. As I'm a firm believer, we can only get better if we truly listen to our Developers pain points. And take action where feasible, and appropriate. Hopefully we can talk soon. 

Kind regards,

Ashton Jordan
Developer Experience Manager