Client Credentials

There are three types of client secrets in ADAL4J:

• Application Secrets
• Certificates
• Optimized Client Assertions

Client Credentials with application secret in ADAL4J

During the registration of a the confidential client application with AAD, a client secret is generated (a kind of application password). When the client wants to acquire a token in its own name it will:

• Instantiate a ClientCredential class, passing both the clientId of the application and the clientSecret, both which should be strings.

• Call any of the overrides of acquireToken taking as parameter ClientCredential.

  ​

Client Credentials with certificate in ADAL4J

This time, when the application is registered with AzureAD, it uploads the public key of a certificate. When it wants to acquire a token, the client application will

• Instantiate the AsymmetricKeyCredential, passing the clientId of the application, the RSA private key to sign the assertion, and a X509Certificate.
• Pass it on to any of the acquire token overrides that take an AsymmetricKeyCredential as a parameter.

​

Client Assertion in ADAL4J

There is another way for an application to prove its identity, providing a client assertion, using the ClientAssertion class. To do so:

• Instantiate the ClientAssertion , passing the JSON web token (JWT) as the credential.

One might wonder why have the ClientAssertion class whereas the ClientCredentials class already exists for application secret and the ClientAssertionCertificate is used for the certificate case.

This is actually because:

• Cryptographic operations are very expensive, and when using AsymmetricKeyCredential, they need to happen each time there is a call to AzureAD.
• Also, some developers don't feel comfortable passing a certificate to ADAL4J. Therefore, they have the possibility of creating a client assertion themselves, and passing it to ADAL4J. Note that there a no examples using it.