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 Azure AD, 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 using the clientId of the application and the clientSecret, both of which should be strings.

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

Client Credentials with certificate in ADAL4J

In this case, when the application is registered with Azure AD, it uploads the public key of a certificate. When it wants to acquire a token, the client application will

• Instantiate the AsymmetricKeyCredential using the clientId of the application, the RSA private key to sign the assertion, and a X509Certificate.

• Pass it 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 using 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 AsymmetricKeyCredential 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 Azure AD.
• 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. There are no samples demonstrating it.