## 4.1.6.3.9 Best Practices When Handling Access Tokens
Calls to SAP Authorization and Trust Management service can fail for many reasons, including network latency, connection errors, service downtime, idle connections closed by routing components and so on. The following sections provide recommendations on when to retry connections and the caching of tokens.
How your application handles access tokens has an impact on its resiliency. Cache tokens to avoid running into the rate limiting restrictions of the SAP Authorization and Trust Management service. Retry with cached tokens instead of always getting a new one.
For recommended configuration settings, see Security Considerations for the SAP Authorization and Trust Management Service [page 3234].
## Retry Mechanism
When your application or service tries to get a token and fails, retry the connection. A retry mechanism helps your application handle temporary issues. We recommend retrying token retrieval three times by default. The following table lists when to retry and how often.
Retry and Backoff for Different HTTP Responses
| Event Type       | HTTP Status Code                                                                                                             | Retry                         | Backoff Policy                                    |
|------------------|------------------------------------------------------------------------------------------------------------------------------|-------------------------------|---------------------------------------------------|
| Connection error | None                                                                                                                         | Yes, retry up to three times. | Initial retry after 300 mswith a multiplier of 2. |
| Timeout          | • 408: Request timeout • 502: Bad gateway For example, request timeout from a Cloud Foundry Gorouter. • 504: Gateway timeout | Yes, retry up to three times. |                                                   |
| Rate Limiting    | 429: Too many requests                                                                                                       | Yes, retry up to three times. | Base retry on the Retry- After header.            |
| Event Type     | HTTP Status Code                                          | Retry                         | Backoff Policy                                     |
|----------------|-----------------------------------------------------------|-------------------------------|----------------------------------------------------|
| Other Events   | • 500: Internal server er- ror • 503: Service unavailable | Yes, retry up to three times. | Initial retry after 1000ms with a multiplier of 3. |
| Access Control | • 401: Unauthorized • 403: Forbidden                      | No, don't retry.              | None.                                              |
## Token Cache
We recommend that you cache access tokens in your application as long as they're valid, instead of always getting a new token. If you constantly get a new token, you risk running up against the rate limits in the service and downtime for your application.
For more information, see Rate Limiting [page 3243].
However, renewing tokens before they actually expire improves the resiliency of your applications. If your application only renews tokens at their expiration and the service isn't available at that moment, your users experience a downtime. For example, if your token validity is set to 12 hours, try to renew the token after 6 hours.
Having a local cache also improves the performance of your applications.
Implement a method to remove invalid tokens from your cache. When your application calls with a token from your cache and receives the return codes in the following table, remove the token from your cache and request a new token.
Triggers for Removing Tokens from Your Cache
| HTTP Status Code   | Potential Causes                                                                                                                                                                                    | Application Response                                     |
|--------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| 401: Unauthorized  | • The signing key of the token was rotated. For more information, see Rotate Signing Keys of Access Tokens [page 2384]. • Token expired and your application hasn't removed it from your cache yet. | Remove the token from the cache and request a new token. |
| 403: Forbidden     | Occurs if the token is valid but a scope is missing.  Note Scopes of the client or user can have changed during the caching period.                                                                |                                                          |
##  Tip
SAP Authorization and Trust Management service ensures that keys remain valid for 2 hours after key rotations. Exception: When subaccount administrators force a key rotation, the key is immediately invalid. We recommend that you configure your cache with a 2-hour time-to-live (TTL). If you use a longer TTL, your application must be able to invalidate cache entries when the service responds with 401. Have your application only retry once on failure.
##  Restriction
When administrators force key rotation, applications that use cached tokens must accept a downtime until their caches have been cleared.
## Related Information
https:/ /github.com/SAP/cloud-security-services-integration-library/tree/main/token-client#cacheconfiguration