Microsoft identity providers work with two types of libraries:
- Server middleware libraries: Web apps use server middleware libraries for user sign-in. Web APIs use server middleware libraries to validate tokens that are sent by native clients or by other servers.
Microsoft developers produce and maintains two client Open Source libraries for Java that work with Microsoft identity providers => ADAL and MSAL
They support the industry standards OAuth2.0 and OpenID Connect 1.0
Client Libraries and Microsoft IDP versions
|IDP (Identity Provider)||Client Library|
|AAD v2||MSAL Java (also known as MSAL4J)|
|AAD B2C||MSAL Java (also known as MSAL4J)|
MSAL Java Project Entry point in GitHub https://github.com/AzureAD/microsoft-authentication-library-for-java
MSAL Java sample applications https://github.com/AzureAD/microsoft-authentication-library-for-java/tree/dev/src/samples
ADAL is an older library, used to communicate with identity providers such as ADFS and older versions of AAD v1 token and authorize endpoints
Project source code in GitHub https://github.com/AzureAD/azure-activedirectory-library-for-java
Sample Java application https://github.com/Azure-Samples/active-directory-java-webapp-openidconnect
There is also an oauth2-oidc-sdk for Java that contain the namespaces needed for token deserialization, token validation(s) and processing of claims, which is typically done server side, when the web app or api receives a bearer token in the HTTP(S) Security Authorization Header.
To my knowledge, this SDK is not maintained by Microsoft.
Note: Server side validation of the token, specifically, the decryption of the token digital signature and the comparison of the decrypted hash vs. the calculated hash is critical to ensure the token claims weren’t tampered in transit and that the IdP wasn’t spoofed. There are other token validations, but this one in particular guarantees the integrity of the information and the source of the token.
This needs a good POC!