## 4.1.6.3.7 Validation and Revocation of Access Tokens
To confirm that access tokens were truly issued by the SAP Authorization and Trust Management service and are still valid, applications check the tokens for validity.
Access tokens are JSON web tokens (JWT). When the SAP Authorization and Trust Management service issues access tokens for an application, the service sets a validity and digitally signs the token. The default validity for a token is 12 hours, but you can set the validity as part of the OAuth configuration in the application security descriptor ( xs-security.json ).
Applications must reject the access token in the following cases:
- The token is no longer valid. The token could have expired or has been revoked.
- The signature on the token doesn't match.
## Online or Offline Validation
As an application developer, you have the design decision, whether to perform validation of the token online or offline.
In online validation, you send a request to the SAP Authorization and Trust Management service to determine that the access token is still valid and hasn't been revoked. To check the validity, use the introspect endpoint of the standard Cloud Foundry API.
Your application can perform offline validation with the help of our client libraries. You must get the public key from the SAP Authorization and Trust Management service and use the key to check the validity. While validating a token offline can ensure that your application can continue to operate if the SAP Authorization and Trust Management service is unavailable, your application continues to accept revoked tokens until they reach the end of their validity. A malicious user with a revoked token still has access as long as the token is still valid.
To revoke a token, use the revoke endpoint of the standard Cloud Foundry API.
## Related Information
Rotate Signing Keys of Access Tokens [page 2384]
Application Security Descriptor Configuration Syntax [page 576]
https:/ /docs.cloudfoundry.org/api/uaa/version/74.4.0/index.html#introspect-token https:/ /docs.cloudfoundry.org/api/uaa/version/74.4.0/index.html#revoke-tokens
XSUAA authentication and authorization service integration libraries and samples for authenticating users and services on GitHub
4.1.6.3.8 Include Tokens from Corporate Identity Providers or SAP Cloud Identity Services in Tokens of the SAP Authorization and Trust Management Service
In scenarios where your SAP BTP application interacts with applications that don't support tokens issued by the SAP Authorization and Trust Management service, but require a token from a corporate identity provider or SAP Cloud Identity Services, you can configure SAP Authorization and Trust Management service to include this token.
## Prerequisites
- Trust with an SAP Cloud Identity Services tenant is configured with OpenID Connect (OIDC).
For more information, see Establish Trust and Federation Between SAP Authorization and Trust Management Service and SAP Cloud Identity Services [page 2282].
- Trust with a corporate identity provider by your SAP Cloud Identity Services is configured with OIDC. For more information, see Configure Trust with OpenID Connect Corporate Identity Provider in the SAP Cloud Identity Services documentation.
- The initial logon of your application uses the authorization code flow.
## Context
Imagine you have an on-premise SAP system that trusts your corporate provider. You want to access data in that system from an application on SAP BTP. Your application can get a token from the SAP Authorization and Trust Management service, but you don't want to or can't configure your SAP system to trust that token.
In this scenario, configure the SAP Authorization and Trust Management service to embed the token of a corporate identity provider trusted by the trusted SAP Cloud Identity Services tenant. In this example, before the SAP BTP application makes a service call to the Cloud Connector proxy, the application calls the SAP Authorization and Trust Management service to exchange its current token for a new token that embeds a token from the identity provider. Cloud Connector presents the identity provider token to the on-premise SAP system.
The following figure illustrates this scenario.
## Cloud Connector Using Embedded Tokens
<!-- image -->
##  Caution
Token embedding is provided as a best-effort solution. The BTP application must be designed to fail gracefully when the SAP Authorization and Trust Management service is unable to embed tokens from SAP Cloud Identity Services or the corporate identity provider. SAP Authorization and Trust Management service records such events in the audit log.
## Procedure
1. When deploying your application, ensure that the application security descriptor ( xs-security.json ) sets the system-attributes with one of the following options:
| Value                   | Description                                                                                                                                |
|-------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|
| ias-corporate-idp-token | Embeds the token of the corporate identity provider trusted by your SAP Cloud Identity Services tenant in the token issued by the service. |
| ias-token               | Embeds the token of your trusted SAP Cloud Identity Services tenant in the token issued by the service.                                    |
For more information about the application security descriptor, see Application Security Descriptor Configuration Syntax [page 576].
2. In the SAP Cloud Identity Services application that represents your SAP BTP application, add the self-defined attribute xsuaa-persist-corporate-idp-token with the Expression source and true value.
This attribute ensures that the service knows to embed the tokens.
For more information, see Configuring Attributes Based on Flexible Expressions in the SAP Cloud Identity Services documentation.
## Results
The service can embed tokens of trusted identity providers in its tokens.
##  Caution
Your deployed application might not receive a token from the corporate identity provider even if it is configured to recognize the token from the corporate identity provider.
We recommend that applications implement one retry for the token retrieval if the received token does not contain the corporate identity provider token. Additionally, applications should react appropriately if the corporate identity provider token is still missing after the retry.
To analyze the issue, refer to the auditing and logging information. See Auditing and Logging Information for SAP Authorization and Trust Management Service [page 3198].
## Next Steps
If you use Cloud Connector, ensure that the service doesn't trust the SAP Authorization and Trust Management service. To use the token of the corporate identity provider, ensure that the service doesn't trust the SAP Cloud Identity Services tenant, too.
For more information, see Configure Trusted Entities in the Cloud Connector in the documentation of SAP BTP Connectivity.