Regarding Access token for WxCC

[ShaktiChawla19265]

Hi, 
We are trying to integrate with WxCC, wanted to understand if it's possible for different servers to get access token with the same clientId and client secret?

Does the WxCC gives same token to both request or does the last access-token invalidates the previous token ?

Thanks!

[bill.king1]

I might not be following what you want to do but for instance I can log into WxCC with an admin account from multiple browsers on the same PC with no issue, is that what you're looking to do some variation of?

[ShaktiChawla19265]

Thanks @bill.king1 for showing interest in this.

What we are looking for is  - if an admin user adds a new application to integrate with WxCC and gets client id and secret, which can then be used to gain the access-token. This access-token can then be used for invoking WxCC api, for example to get the agent activities. 
For resilience we want that an application running on multiple servers and get the agent activities. 

In order to achieve this, the application needs to use the same access-token. 

My question here is there a possibility that the application running multiple servers get their own access-token using the same clientId and clientsecret and use that to invoke a WxCC api ?

[david.macias]

I'm hoping Cisco can answer this as it's a good question. What we've done when we have QA and PROD is have two separate accounts with two distinct client IDs. @Arunabh Bhattacharjee should be able to help. OAuth2 could allow for multiple different tokens, but it depends on how Cisco has configured this.

david

[Arunabh Bhattacharjee]

@ShaktiChawla19265 a client Id/Secret pair identifies an App. It is not for an instance or dev/QA/Prod etc which is why you are able to add several callback URLs while fetching tokens

APP_NAME = Cisco Community Forums

USE_CASE = Sign in with Webex

CLIENT_ID= <unique>

CLIENT_SECRET=<unique>

CALLBACK_URL_LOCAL=http://localhost:8080/auth/callback

CALLBACK_URL_DEV=http://dev.app.com/auth/callback

CALLBACK_URL_QA=http://qa.app.com/auth/callback

CALLBACK_URL_PROD=http://prod.app.com/auth/callback

etc. 

The App clientid/secret pair is able to generate a total of MAX tokens for a given user but generate tokens for Any user across any org. 

I would always suggest devs to think of Sign in with "LinkedIn/Twitter/Google/Facebook" and add "Webex" to the mental model when thinking about OAuth2. The Client ID/Secret identifies your app to Cisco/Webex. 

And you can have any number of instances and any number of running services with the same secrets.

[david.macias]

Thank you for the awesome response like always @Arunabh Bhattacharjee . One thing, what is the max tokens that can be given out? You posted MAX and maybe meant to post a number. Now, I might be a little dense this evening. If you have the same ID and Secret accross multiple apps, what happens when it's time to refresh the token? Does each app get its own token which can be refreshed without affecting the other apps using the same Id and Secret?

david

[ShaktiChawla19265]

that is indeed my follow up question and intent of my original question.
Does the new token invalidates existing token, looking at the answer  its not I think but what impact does a refresh has on existing tokens? 

[Arunabh Bhattacharjee]

Yes so @david.macias  @ShaktiChawla19265  one user can actually have several active tokens for the expires_in timer - at this time it is 12 hours expiry of the token and maximum tokens is 750 - this is explained in the guide and well documented in FAQ

https://developer.webex.com/docs/frequently-asked-questions 

 to revoke - you would need to use the delete authorizations flow - the authorizations would show you how many tokens you issued to the user

https://developer.webex.com/docs/api/v1/authorizations

What this means is: if user@cisco.com logs into your app, they can log in 750 times if you regenerate a new token upon every flow - and if you dont revoke during logout properly can have 750 active tokens in circulation. The moment you generate an access token for the 751st time within 12 hour window you will get an error.

Like David said there is a revoke token flow (delete authorization) where you should ideally revoke someone's token when they sign out / invalidate the session / done with the API call. Or refresh the token after 12 hours window so that in 12 hours you just generate 1 token per user. 

Again, this does not limit the number of users logging into your app. this doesnt mean the client ID can only log in 750 users at a time. This means that if you get a user's token say user@cisco.com then you cannot refresh the token 751 times within 12 hours without revoking the previous tokens. which means all tokens are active for 12 hours and are valid tokens. like you'll have mentioned:

- Either refresh the token after access token expiry - just before 12 hours 

- store access and refresh tokens and refresh the access token just before 12 hour expiry 

[ShaktiChawla19265]

thanks @Arunabh Bhattacharjee for the clarification and suggestion.