Tag: oauth2.0

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!

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.