Legacy Dev Forum Posts

 View Only

Sign Up

Authorization type selection: rate limit on client credentials grant vs. users permissions on authorization code grant

  • 1.  Authorization type selection: rate limit on client credentials grant vs. users permissions on authorization code grant

    Posted 06-05-2025 18:22

    irena | 2022-06-21 03:48:37 UTC | #1

    Hello,

    An application we develop for Genesys users allows users to read and modify their schedules via our application under certain business approved conditions. Users can only make those operations via the application, not in their Genesys account directly.

    To support this functionality we use Javascript SDK with Client Credentials Grant authorization type as it allows us to add required permission scopes for the application itself, without giving any additional permissions to the users who interact with the application. However, since the application performs many actions on behalf of a user, the app hits the rate limit on some requests, even when performing operations for a few users. Since we cannot allow users to perform operations similar to the app, e.g. read BU forecast, we cannot use Authorization Code Grant authorization type as it requires adding permissions for the users.

    Could you please advise on the correct authorization type for this case?

    Thank you. Irena


    jacobshaw | 2022-06-21 17:27:58 UTC | #2

    Hi @irena Not sure why the client credentials are costing you more api requests, could you expand on this?

    To avoid rate limiting, try:

    • Reduce the overall number of API requests from the application. This can be accomplished by:
      • Optimizing code to eliminate unnecessary API calls
      • Cache API responses
      • Use the notification service to track user presence, conversation state, and other data points that change regularly
    • Regulate the rate of API requests using one of the following:
      • Reduce the frequency of API requests
      • Apply a throttle to API requests
      • Implement an exponential backoff mechanism in response to 429 errors

    Sourced from: https://developer.genesys.cloud/platform/api/rate-limits


    irena | 2022-06-21 21:10:51 UTC | #3

    Hi @jacobshaw,

    Thank you for your prompt reply. To elaborate on the issue with the client credentials, here are more details about a specific API we hit limit on, postWorkforcemanagementBusinessunitIntraday. Fresh data from this API is required by the app functionality in several separate common scenarios. When multiple users use the app, the API is called that more frequently (as each user's operations require fresh data from this API). Since the API is called with the same client credentials grant on behalf of all users, we hit the API limit, which is 60 calls per minute (despite documentation, pls see responses in another post: https://developer.genesys.cloud/forum/t/postworkforcemanagementbusinessunitintraday-rate-limit/15071).

    Using user's tokens instead of client credentials would resolve the rate limit issue, however this would require giving users a permission they should not have.

    There are other APIs we need to call often, so the above issue is not specific for this API only.

    If we continue with the client credentials grant, we will employ the approaches you suggested, however this might not be sufficient to accommodate the number of users that app needs to support and the existing API rate limits.

    Thank you. Irena


    tim.smith | 2022-06-22 15:52:23 UTC | #4

    irena, post:3, topic:15241
    Using user's tokens instead of client credentials would resolve the rate limit issue

    @irena the behavior you're experiencing sounds expected. You're using client credentials inappropriately to bypass user authorization. The limits in the platform have been put in place with the expectation that users will authorize individually and client credentials will only be used by non-user service applications. User-based applications should always use a user-based OAuth grant (i.e. anything but client credentials) to allow the application to be authorized by the user that's using it.

    irena, post:3, topic:15241
    however this would require giving users a permission they should not have.

    Can you elaborate on this concern? Why do you believe the users should not have permissions to do the task you're allowing them to perform?

    The WEM dev team is monitoring this post for general feedback, but if you have specific requests for features, you can make the request and share your use case at https://genesyscloud.ideas.aha.io/.


    irena | 2022-06-23 01:22:40 UTC | #5

    Hi @tim.smith,

    As stated in the original post, our app allows users to do some operations, e.g. modify their schedule, under certain business conditions, however they should be able to make changes via the the app only (when certain conditions are verifies by the app). So, the app makes changes on behalf of users, and is using client credentials to avoid giving users permissions that would allow them to make similar changes in their account directly.

    Maybe there is another way to achieve that: use user credentials in the app, without providing users with additional permissions?

    Regards, Irena


    brian.trezise | 2022-06-28 06:26:47 UTC | #6

    It sounds like you're wanting to delegate permission to do certain things to an app that further limits what users are allowed to do beyond what our permissions allow. That's a fair use case, we just don't have a great solution given the limits we have in place. Our auth mechanism and general rate limits don't allow for a monolith sever-to-server type of integration that has a single authenticated context for all users. For that type of integration, we'd still expect the integration to use a code auth grant and authorize each user individually and use the correct auth token for each request.

    This does however sound similar to something we're considering implementing in the long term, I'd encourage you to visit the Genesys Ideas Portal here: https://genesyscloud.ideas.aha.io/ to share details of your use case.


    system | 2022-08-19 09:28:58 UTC | #8

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


    This post was migrated from the old Developer Forum.

    ref: 15241