I am retrieving an Implicit Grant access token and using it to call PostConversationsCalls(). I have specified 48 hours for the token expiration and it is returned with an expiration of 48 hours. Everything works fine for a while, however, at some point within an hour the token becomes invalid and I can no longer access the API. This is the error message returned...
There's not a guarantee that tokens will be valid for their entire duration; the expiry time should be considered a "not longer than" value. Well-formed apps will always handle becoming unauthorized gracefully and will automatically take appropriate steps to obtain a new token whenever it's necessary.
If you need to track down exactly why a specific token became invalidated, please open a case with Genesys Cloud Care as we do not have access to your org's data via the forum.
I may have missed something, but from what I've read the .NET SDK does not support the standard oAuth refresh token functionality. That would seem to be quite problematic if the tokens expire before their stated expiration. I certainly can't expect the user to login every hour. Please let me know if there is something I have overlooked.
I'm a bit unsure about the .NET SDK myself. it is stated in the documentation that
By default, the SDK will transparently request a new access token using the refresh token when the access token expires. If you wish to implement the refresh logic set ShouldRefreshAccessToken to false and store the refresh token from the auth response:
However, that paragraph is only in the Authorization Code Grant section. I'm using the Client Credentials Grant, and I'm not even seeing a refresh token in my PostToken response.
Looking at the source code of the .NET SDK, in ApiClient.cs we have the CallApi method which has these conditions for automatic transparent token refresh:
if (UsingCodeAuth && Configuration.ShouldRefreshAccessToken)
UseCodeAuth is only set to true on
if (!string.IsNullOrEmpty(redirectUri))
Since Client Grants have no redirect URIs, in my case and the token request doesn't return a refresh token in neither content nor header. The implicit grant however seems to support a redirect URI, so I figure that should work (@mark-at-healthsmart : are you seeing a refresh token when you sniff the traffic using a proxy like Fiddler?)
@tim.smith : Are you referring the ability to delete token, e.g. using the token APIs when you say there's no guarantee that a token? Or are there other token invalidation mechanisms that may occur?
This is a standard feature of OAuth. Applications are always expected to be reactionary and be able to reauthorize at any time. As mentioned before, please open a case with Genesys Cloud Care if you need to identify why a specific token was invalidated.
The auth code grant is the only grant type that uses refresh tokens. All other grant types must always re-initiate the full OAuth flow to get a new auth token.
I understand that I could easily get a new token silently using the Client Credentials grant credentials without involving the user. However, it is my intention to place outgoing calls and inspect incoming calls. I need to do this in the context of an authenticated user. It appears from your statement...
The auth code grant is the only grant type that uses refresh tokens. All other grant types must always re-initiate the full OAuth flow to get a new auth token.
... that I must have the user must login again. Please confirm my interpretation. If this is the case, the project will need to be abandoned.
Correct. If the user lacks a valid auth token, they must complete an OAuth flow to get a new one.
This is incorrect. You should not abandon the project. Simply re-initiate the same oauth flow you used to get the first auth token when necessary; there's no difference in the process between the first time and the n+1th time, except that if the user still has a valid auth cookie they won't even see the login screen and the flow will complete instantly. Or if you're using the auth code grant and still have a valid refresh token, use the refresh token to get a new auth token.
I would strongly encourage you to open a case with Genesys Cloud Care to investigate if you're seeing issues with tokens becoming expired before you expect. They can track down what's happening to explain what you're doing that's causing it to happen.
Is there any chance you'd consider adding code to transparently reauthenticate with client credentials, too? I'd be happy to have a go at it, but I don't like having to maintain my fork thereafter. It would be much more convenient and simply to re-use the logic that's already there (I'm thinking another config flag to enable transparent re-auth, then store clientId/secret not only for code-auth but also when transparent client credential re-auth is enabled, and calling PostToken with just clientId/secret in the HandleExpiredToken method)
We maintain all the available capabilities consistent across different lang SDKs and this is something which needs to be applied across all SDKs. Please feel free to request this new feature and share your use case at https://genesyscloud.ideas.aha.io/
Took me a couple of minutes only. It would take much longer to actually change the code that I build around the .NET SDK to catch ApiExceptions, look at ErrorCode, re-authenticate and retry the API request than these small changes..
For the benefit of others who may run into this issue... I did open a case and it turns out that if the org is flagged as 'HIPAA Enabled' then an inactivity timeout of 15 minutes is applied, invalidating the auth token, overriding all other timeout or token expiry settings.
As a workaround, I have implemented a 'keep alive' function on a background thread within the app and it appears to be successfully circumventing the issue.