Our automated resource allocation jobs in ICS 2023-1 started failing three days ago with authentication errors. The token expiry issue is confirmed - tokens are expiring after exactly 60 minutes despite configuration showing 3600 seconds. Manual token refresh through the API gateway works perfectly and jobs run successfully afterward, but automation breaks again after the next expiry.
I’ve checked the API gateway settings multiple times and the token lifetime configuration appears correct:
The automation framework doesn’t seem to be handling refresh tokens properly. Has anyone encountered this specific behavior where manual refresh works but automated refresh fails? We’re running critical resource planning jobs every 2 hours and this is blocking our operations.
Here’s the complete solution based on your findings:
Root Cause Analysis:
Your issue stems from three interconnected problems: (1) The tenant-level OAuth policy limiting access tokens to 60 minutes overrides your gateway configuration, (2) Your automation framework only stores access tokens without implementing refresh token logic, and (3) Manual refresh works because you’re issuing fresh client credential grants each time.
Implementing Proper Token Refresh:
First, update your authentication handler to capture both tokens:
Implement proactive refresh before expiration (5 minutes before expiry is safe):
if time.now() >= expiry_time - 300:
refresh_response = oauth_client.refresh(refresh_token)
access_token = refresh_response['access_token']
refresh_token = refresh_response['refresh_token'] # Update this too
expiry_time = time.now() + refresh_response['expires_in']
Addressing All Three Focus Areas:
Token Expiry Confirmed: Accept the 60-minute limit as enforced by tenant policy. Don’t try to override it at the gateway level - work with it through proper refresh implementation.
Manual Refresh Works: Your manual process was actually doing full re-authentication (client credentials grant), which always works but is inefficient. The automated solution should use refresh tokens instead, which is the OAuth2 best practice.
API Gateway Settings Checked: Your gateway settings were correct but being overridden. The real configuration to address is at the tenant OAuth policy level. If you need longer-lived tokens, work with your Infor administrator to adjust the tenant policy, but implementing refresh tokens is still the right architectural approach.
Additional Implementation Recommendations:
Token Storage: Use a secure token cache (Redis or similar) shared across automation instances to prevent redundant authentication calls
Error Handling: Implement retry logic with exponential backoff for refresh failures, falling back to full re-authentication if refresh token is invalid
Monitoring: Add logging around token refresh events to track success rates and identify patterns in failures
Concurrency: Use locking mechanisms if multiple jobs run simultaneously to prevent race conditions in token refresh
Security: Encrypt refresh tokens at rest and ensure they’re never logged or exposed in error messages
This approach will handle your resource allocation jobs reliably, even with the 60-minute token lifetime. The refresh token flow is designed exactly for this scenario - long-running or frequently scheduled automation that needs to maintain API access beyond the access token lifetime.
This draft is based on general Infor CloudSuite knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
I’ve seen similar behavior with ICS 2023-1 API integrations. The issue is often that your automation client isn’t implementing the OAuth2 refresh flow correctly. When you manually refresh, you’re probably using a new client credentials grant, but your scheduled jobs might be trying to reuse expired access tokens. Check if your automation framework is capturing and storing the refresh token from the initial authentication response.
Thanks for the quick response. You’re right - I reviewed our automation scripts and they’re only storing the access token, not the refresh token. The initial authentication call does return both tokens in the response JSON. Should I be using the refresh token endpoint instead of requesting new credentials each time?
Yes, definitely use the refresh token flow. When your access token is about to expire, call the token refresh endpoint with your refresh token. This is more efficient than repeatedly authenticating with client credentials. The refresh token typically has a much longer lifetime (often 24 hours or more in Infor OS). Just make sure you’re also updating the refresh token when it’s returned in the refresh response, as some implementations rotate refresh tokens for security.
One thing to watch out for - verify that your API gateway token lifetime setting is actually being applied. I’ve encountered cases where the gateway configuration was correct but the backend OAuth service had a separate timeout configured that was overriding it. Check your Infor OS admin console under Security → OAuth Configuration to see if there’s a maximum token lifetime policy enforced at the tenant level. Also, your refresh window of 300 seconds seems reasonable, but ensure your automation triggers the refresh before that window closes.
Great catch Laura! I found a tenant-level policy limiting access tokens to 60 minutes regardless of gateway settings. That explains the consistent expiry behavior. Now I need to properly implement the refresh token flow in our automation. Raj, do you have any code examples for the refresh call?
I’ll add one more consideration - implement exponential backoff for your token refresh attempts. Network hiccups can cause refresh calls to fail, and you don’t want your automation retrying too aggressively. Also consider implementing a token cache with time-to-live tracking so multiple concurrent jobs can share the same valid token rather than each requesting their own. This reduces load on the OAuth service and prevents potential rate limiting issues during high-volume automation periods.