## 6.1.1.8.5.1  Service Instance Secrets
When an application consumes a service instance of the SAP Authorization and Trust Management service (XSUAA), the application identifies itself to the service instance with a client ID and a secret. The client ID and secret are the credentials with which an application authenticates itself to the service instance.
The SAP Authorization and Trust Management service (XSUAA) creates these credentials either when you bind the application to the service instance or when you create a service key for the service instance.
The service instance can use multiple secrets in the application plan.
- The secret is the same for all bindings of the service instance. The secret remains valid as long as the instance exists.
<!-- image -->
- The binding secret is the default secret type. Binding secrets must be enabled in the application security descriptor ( xs-security.json ) when you create the service instance. When you bind an application to a service instance or create a service key, you can pass a parameters.json to use a binding secret. The secret remains valid as long as the binding or the service key exists.
##  Note
The apiaccess plan only uses binding secrets. However, some old instances of the apiaccess plan still use the instance secret.
- X.509 secrets must be enabled in the application security descriptor ( xs-security.json ) when you create the service instance. When you bind an application to a service instance or create a service key, you can pass a parameters.json to use an X.509 secret. SAP Authorization and Trust Management service can generate an X.509 certificate for you or you can provide your own. The X.509 secret remains valid as long as the certificate itself is valid.
##  Note
The service doesn't check for certificate revocation. To stop the service from accepting a certificate that is still valid, delete the relevant bindings or service keys. As soon as the binding is deleted, the service stops accepting the certificate.
For bindings with self-managed certificates and the certificate-pinning parameter set to false , you can rotate the secrets without deleting bindings. Just use a new certificate with the same subject and issuer distinguished name (DN). The service saves the new validity date of the new certificate.
For more information, see Parameters for Self-Managed X.509 Certificates [page 2381].
The following figure illustrates the XSUAA app and the binding information about the OAuth 2.0 client as part of a service instance of the SAP Authorization and Trust Management service. A consuming application, functioning as an OAuth 2.0 client is bound to the SAP Authorization and Trust Management service instance. The secret is part of the environment of the consuming application and the information about the OAuth 2.0 client saved with the XSUAA app. Alternatively, this information is saved as part of a service key.
Binding Between an SAP Authorization and Trust Management Service Instance and a Consuming Application
<!-- image -->
The credential-types parameter of the OAuth client configuration in the application security descriptor ( xs-security.json ) determines which types of secrets that bindings support.
In the following example, the service instance creates a binding secret for all new bindings. It allows the creation of X.509 secrets and still accepts instance secrets.
```
 Example  Sample Code "oauth2-configuration": { "credential-types": ["binding-secret","x509","instance-secret"] }
```
In the following example, the service instance creates a binding secret for all new bindings, but doesn't accept the instance secret or the use of X.509 secrets.
<!-- image -->
## Related Information
Rotate Binding Secrets [page 2373]
Rotating Instance Secrets [page 2377]
Migrate from Instance Secrets to Binding Secrets [page 2376]
Application Security Descriptor Configuration Syntax [page 576]
Limits for Technical Artifacts of the SAP Authorization and Trust Management Service [page 3248]