Category: IdentityManagement

OAuth2/OIDC Libraries for Java that work with Microsoft IDPs

Microsoft identity providers work with two types of libraries:

  • Client libraries: Native clients (iOS, Android), JavaScript SPA applications,  and servers use client libraries to acquire access tokens for calling a resource such as Microsoft Graph or other APIs.
  • 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 v1 ADAL4J
ADFS OAuth/OIDC ADAL4J
AAD v2 MSAL Java (also known as MSAL4J)
AAD B2C MSAL Java (also known as MSAL4J)

MSAL Reference: https://javadoc.io/doc/com.microsoft.azure/msal4j/latest/index.html

MSAL Java Wiki https://github.com/AzureAD/microsoft-authentication-library-for-java/wiki

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

ADAL Reference https://javadoc.io/doc/com.microsoft.azure/adal4j/latest/index.html

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.

https://www.javadoc.io/doc/com.nimbusds/oauth2-oidc-sdk/latest/index.html

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!

Managing external identities with AAD B2C tenants – public docs

Azure AD B2C is one of the most fast growing Identity Providers in the world. When this type of tenant was created for social identities and digital citizens, the Microsoft Identity team didn’t anticipate its massive growth. Over 1 billion of users authenticate to their apps, and apps to apis, using this type of Azure directory or tenant. When privacy norms such as GDPR in the European Union and CCPA in California, USA, came about, the flexibility provided by custom policies; the white label customization of the html/css and the Identity Experience Framework, allowed solutions where the end users have more control of their data, including the ability to remove the personal data that applications collect from them (profile information, credentials, user attributes and permissions). Microsoft Graph also provides one of the first RESTful APIs that allow application developers to programatically perform CRUD operations on user accounts and principals associated to applications and services.

This month the Microsoft Identity team has published a number of public articles to guide developers on the automation steps with Azure AD B2C:

Choosing an OAuth2.0 grant flow for your solution.

A colleague of mine that also specializes on Identity Management (IdM) with Identity Providers (IdP) such as AAD, Okta, ADFS, Ping Federate and IdentityServer, published this summary on the 6 different flows encompassed by the OAuth2.0 RFCs.

If you work with the OAuth 2.0 Authorization Framework and the OIDC Authentication Framework, you’ll find the article below very interesting.

https://mrochon.azurewebsites.net/2019/06/04/choosing-an-oauth2-grant-flow/

One thing to remember when you study the Authorization Grants or Flows in OAuth2.0 is that neither the Extension Grant flow nor the Client Credentials flow require the end user to interact with a browser.

The Client Credentials Flow is designed for headless daemons/services where the is no human interaction. The Extension Grant Flow is sometimes named as OBO (on-Behalf-of) and can be used to exchange SAML2.0 tokens for OAuth2.0 access tokens/bearer tokens. This grant (Extension Grant) doesn’t necessarily require user interaction during the token exchange at the IdP for an authorized application if the token being exchanged is still valid. (OAuth2.0 Extension Grant) In this case the SAML2.0 bearer token with its assertions is exchanged for an access token/bearer token/JWT that represents the client application or service.