Add a page on the GitHub Wiki on how to use the Msal Java token cache.

How to get a token for MSI

Hello MSAL4J team,

i am getting below error when i am trying to cleate "ConfidentialClientApplication" using client id and client secret for "ADFS" authority:
"Unsupported authority type. Please use AAD authority".

i need to use only ADFS as authentication server.

i know we have ADFSAuthority class in the msal4j JAR but "ClientApplicationBase" class doesnt provide have code for "ADFS" authority type. i am using msal4j - "0.5.0-preview" maven dependency.

kindly help and advice. Is there any updated library?

Thanks,
Mukul

I'm writing a webapp, where I want to use the msgraph api on a user's behalf even if that user is offline.

For This I'm using the authorization code flow.

Everything is working fine so far. I redirect the user to the login page, and on return get the AuthenticationResponse. This response I use to get an IAuthenticationResult that I can use to access the msgraph api.

I serialize the TokenCache and store in the db.

Whenever I need to call msgraph later I create a new ConfidentialClientApplication and deserialize the TokenCache.

As far as I can see, all documentation and issues point in the direction of using the authorization code flow again. This way msal4j will automatically request a new refresh token if necessary or return the one in the cache if it still valid.

But i can not find an answer on what I should put in the AuthorizationCodeParameters. In the flow you are supposed to use the refresh token for this. But there is no way to extract the refreshtoken from the TokenCache.

please help, I got this far on my own but can't find any info on what to put in there.

ConfidentialClientApplication clientApplication = ConfidentialClientApplication.builder(msGraphConfiguration.getClientId(), new ClientSecret(msGraphConfiguration.getClientSecret())).build();
clientApplication.tokenCache().deserialize(serializedTokenCache);

clientApplication.acquireToken(AuthorizationCodeParameters.builder("WHAT TO PUT HERE?", getRedirectUrlAsUrl()).build()).get();

Enable customers to get SSO for integrated windows authentication when they have a managed tenant with password hash-sync or pass through authentication, and the device is domain joined. Waiting for server team to whitelist MSAL before testing.

• Create an SSLTunnelSocketFactory
• Set SSLSocketFactory on the AuthenticationContext
• Make a call through a proxy that requires authentication

Two connect calls are made. The first one does not go through the proxy. If you manually set the proxy, the first call will error out with "HTTP/1.0 407 Proxy Authentication Required"

I followed the instructions from this site https://github.com/AzureAD/microsoft-authentication-library-for-java/wiki/Integrated-Windows-Authentication
Unfortunately I'm getting 401 response code with this exception:

[ForkJoinPool.commonPool-worker-1] ERROR com.microsoft.aad.msal4j.PublicClientApplication - [Correlation ID: xxx] Execution of class com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier failed.
com.microsoft.aad.msal4j.MsalServiceException: Server returned HTTP response code: 401 for URL : https://adfs.{company_name}.com/adfs/services/trust/2005/windowstransport
	at com.microsoft.aad.msal4j.HttpHelper.readResponseFromConnection(HttpHelper.java:164)
	at com.microsoft.aad.msal4j.HttpHelper.getResponse(HttpHelper.java:91)
	at com.microsoft.aad.msal4j.HttpHelper.executeHttpPost(HttpHelper.java:78)
	at com.microsoft.aad.msal4j.HttpHelper.executeHttpRequest(HttpHelper.java:47)
	at com.microsoft.aad.msal4j.WSTrustRequest.execute(WSTrustRequest.java:52)
	at com.microsoft.aad.msal4j.WSTrustRequest.execute(WSTrustRequest.java:101)
	at com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier.getAuthorizationGrantIntegrated(AcquireTokenByAuthorizationGrantSupplier.java:126)
	at com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier.execute(AcquireTokenByAuthorizationGrantSupplier.java:40)
	at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:57)
	at com.microsoft.aad.msal4j.AuthenticationResultSupplier.get(AuthenticationResultSupplier.java:17)
	at java.util.concurrent.CompletableFuture$AsyncSupply.run(Unknown Source)
	at java.util.concurrent.CompletableFuture$AsyncSupply.exec(Unknown Source)
	at java.util.concurrent.ForkJoinTask.doExec(Unknown Source)
	at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(Unknown Source)
	at java.util.concurrent.ForkJoinPool.runWorker(Unknown Source)
	at java.util.concurrent.ForkJoinWorkerThread.run(Unknown Source)

I've checked the user, scope, clientId and authorization and they are correct.
When I run C# example with the same user, scope, clientId and authorization everything works fine.

What can be a reason of this problem ?

Enables Integrated Windows Auth in hybrids scenarios with Seamless SSO.

I have a scenario where the application is divided into two desktop programs: a front-end UI and a back-end worker. With ADAL4J, refresh token is exposed in authentication result, which is then passed to the backend through an environment variable. There is no easy way of doing this with MSAL4J. The workaround with serializing the token cache to JSON and reading the refresh token from there is rather cumbersome.

I want to programmatically add/remove users from the Azure AD B2C directory I have. I have made my application 'User administrator'. I also created a client secret in the 'Certificates & secrets' section of my app.

In my Spring boot application, I created this bean:

    @Bean
    public ConfidentialClientApplication clientApplication() throws MalformedURLException {

        return ConfidentialClientApplication.builder("<application-id>",
                                                     ClientCredentialFactory
                                                             .createFromSecret("<client-secret>"))
                                            .b2cAuthority("https://mycompb2ctestorg.b2clogin.com/tfp/oauth2/nativeclient")
                                            .build();

    }

Using this bean, I try to get an access_token:

        CompletableFuture<IAuthenticationResult> future = clientApplication
                .acquireToken(ClientCredentialParameters.builder(Set.of("Directory.ReadWrite.All")).build());
        future.handle((authenticationResult, throwable) -> {
            if( throwable != null ) {
                System.out.println("throwable = " + throwable);
                return null;
            }

            String accessToken = authenticationResult.accessToken();
            System.out.println("accessToken = " + accessToken);
            return null;
        });

When I run this, I get an exception:

java.util.concurrent.CompletionException: com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: 
Expected BEGIN_OBJECT but was STRING at line 1 column 1

When I debug, I see that the JSON is not JSON, but a HTML page with this body:

    <body>
        <div id="header"><h1>Server Error</h1></div>
        <div id="content">
            <div class="content-container"><fieldset>
                <h2>404 - File or directory not found.</h2>
                <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3>
            </fieldset></div>
        </div>
    </body>

What am I doing wrong?

Hello, when i use UserNamePasswordParameters i get the next exception:
"com.microsoft.aad.msal4j.AuthenticationException: {"error_description":"AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.\r\nTrace ID: 1c15bd7a-12b0-4fcc-8f7d-fc4f909b0d00\r\nCorrelation ID: d895e136-9711-4a00-88ff-5fd7da8eb634\r\nTimestamp: 2019-06-26 08:26:25Z","error":"invalid_client"}"

What I do wrong?

When creating a IClientCredential from a certificate, MSAL checks that key length >= 2048.

The Java interface RSAPrivateKey has an API to get the modulus length. We use this API to verify length >= 2048

A problem arises when using certificates stored in Windows-My store. When pulled from the keyStore, the private keys are of type sun.security.mscapi.RSAPrivateKey or sun.security.mscapi.CPrivateKey (JDK12 and greater) and not java.security.interfaces.RSAPrivateKey. sun.security.mscapi.RSAPrivateKey or sun.security.mscapi.CPrivateKey does not expose a length() method, and all other sun.security.* APIs are proprietary, and therefore not all JDKs will include them going forward.

Need to investigate what the recommended way to enable support for certificates stored in "Windows-MY" keystores.

Hi, I request a access_token and refresh_token from https://login.microsoftonline.com/{tenant}/oauth2/token on the backend which base on SpringBoot and response to frontend.

and then frontend send a request to backend api with access_token, the question is how to validate access_token on the backend ? and we alse use Sring Security.

At the moment I did't found any suggestions.

I'm looking forward to your reply as soon as possible.

Currently tokens are cached with tenant id which issued them, this is an issue when "common" authority is used - cached AT will not be found during silent call, so RT will be used and redundant call to STS executed.

I'm wondering whether MSAl4j is considered thread-safe? I.e. is it supported to share
instances of ClientApplicationBase between threads?

Just noticed this while testing out the new Microsoft Identity Platform 2.0 functionality, the currently released version (0.5.0-preview) does not match the sources and documentation released alongside with it.

To be specific, the issue I noticed is that the class com.microsoft.aad.msal4j.AuthorizationCodeParameters is present in the JAR and the source released alongside makes reference to ConfidentialClientApplication#acquireToken(AuthorizationCodeParameters) method which however does not actually exist, the only available overloads are for ClientCredentialParameters and OnBehalfOfParameters. When viewed through IntelliJ IDEA, when opening the class com.microsoft.aad.msal4j.ClientApplicationBase it even puts a red alert box on top with the text "Library source does not match the bytecode for class ClientApplicationBase".

To add to the confusion, this mismatch is also present in the example application at Azure-Samples/ms-identity-java-webapp AuthHelper.java#L187-L192

Cache results of instance discovery request

The AsymmetricKeyCredentials class currently uses sun.security.util.Length, but this is not public API and it is not guaranteed to be included in all JDKs, and is unavailable after JDK 9 due to the introduction of modules. Usage of API in the sun.* namespace is not recommended.

All exceptions returned to users get wrapped in ExecutionException. Instead, we should return the actual exception.

The lab will be retiring api.msidlab.com on October 31st. All tests should be updated to call the new lab API.

Hello, when i use UserNamePasswordParameters i get the next exception:
"com.microsoft.aad.msal4j.AuthenticationException: {"error_description":"AADSTS7000218: The request body must contain the following parameter: 'client_assertion' or 'client_secret'.\r\nTrace ID: 1c15bd7a-12b0-4fcc-8f7d-fc4f909b0d00\r\nCorrelation ID: d895e136-9711-4a00-88ff-5fd7da8eb634\r\nTimestamp: 2019-06-26 08:26:25Z","error":"invalid_client"}"

What I do wrong?

• Update sample to show sign in/ sign out
• Acquire token for graph and use token to show users in tenant
• How to handle MsalInteractionRequired Exception
• Update README with instructions on how to run in:
  • IDE
  • Package in to .WAR and run in tomcat
• Update App creation scripts to work with V2 endpoint

Add a Java quickstart on the azure portal app registration page, with a backing tutorial on docs.ms

The current locking is causing issues for scenarios where a cache file needs to be deleted. This may impact Python and .NET extensibility libraries as well.

Problem description:
The issue is that in Java you have to delete the lock file prior to deleting the file which introduces a race condition with other languages.

The pom.xml file in this project needs review - there are a number of issues I would like to discuss. Primarily, the dependencies listed in the pom.xml file seem to be more than what is required. For example, I'm not clear that javax.servlet is required. Additionally, almost all 'test scope' dependencies aren't actually scoped for test only.

Guava is imported almost needlessly - it appears to be only used in one class where it could be trivially replaced.

Please feel free to ping me at [email protected] so that we can work together to improve this pom file.

Hello msal4j team,

I need to acquire tokens using "implicit" grant flow. i don't see any sample example in github for "implicit" grant flow.
com.nimbusds.oauth2.sdk.id.Identifier.GrantType does have GrantType IMPLICIT.

Also, "com.microsoft.aad.msal4j.AcquireTokenByAuthorizationGrantSupplier class" doesnt implement implicit grant flow.

Could anyone let me know the references to the above problem statement?

I have a doubt that in this case, shall I use - ClientApplicationBase.acquireTokenCommon () to acquire token?

Thanks,
Mukul

Conceptual documentation in https://docs.microsoft.com/en-us/azure/active-directory/develop/ should have links to Java samples, Java GitHub, as well as include Java code snippets for all relevant scenarios

It looks like the Authority class is incorrectly using the selenium InvalidArgumentException instead of java.lang.IllegalArgumentException in the createAuthority method.

Fill in descriptions for public APIs on javadoc - https://javadoc.io/doc/com.microsoft.azure/msal4j/0.4.0-preview

AuthenticationResult should have getAccounts() and getScopes() APIs

Customers should be able to share instances of ClientApplicationBase between threads

Create a quick start, concept to be found here:

Javascript qs, notice how we are using tags for what goes to the portal and docs.
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-v2-javascript

The md file from docs and convert it into HTML based on the tags for it to surface in portal.
Detailed instructions shared internally.

Add helper method for crafting the URL for the authorization code endpoint.

• IClientApplicationBase should be made internal. Calling applications should use either IPublicClientApplication or IConfidentialClientApplication.
• Account should be made internal. Account will always be obtained from calling getAccounts() or from IAuthenticationResult, but never created outside of the library. If such a need arises in the future, we can always make it public again (non-breaking change).
• AsymmetricKeyCredential should be renamed to ClientCertificate. ClientCertificate is simpler, aligns with other libraries, and is the term that is used in documentation.
• ClientSecret, ClientCertificate, ClientAssertion should be made internal. There is no need to leak out these implementation details. Instead, IClientSecret, IClientCertificate, and IClientAssertion will be added.

Found answer ,closing issue.

Regards,
Showkath.

Is your feature request related to a problem? Please describe.

Problem statement

One of common status codes returned from authentication libraries in silent mode today is InvalidGrant. This status code means that the application should call the authentication library again, but in interactive mode. Additional user interaction is required before authentication token can be issued. Note: some versions of libraries also return InteractionRequired status, with exactly the same semantics. The rest of the document will refer to InvalidGrant only, and same decisions apply to InteractionRequired.

Over time, many conditions accumulated in the broad category covered by InvalidGrant status code. As a result, InvalidGrant has become very general, and it is hard for applications to build user experience that correctly handles all the conditions that result in InvalidGrant. Some of those conditions are easy for users to resolve (e.g. accept Terms of Use with a single click), and some cannot be resolved with the current configuration (e.g. the machine in question needs to connect to a specific corporate network).

Depending on how complicated and involved required user interaction is, apps may want to show different user experience for different levels of difficulty of user interaction. For example, if the app is trying to show multiple resources to the user at the same time (e.g. items in a collection returned by a search result), the app may choose to not display specific results for which authentication flow to resolve InvalidGrant condition is too intrusive, but may choose to enable resolution of InvalidGrant condition if resolution is quick and simple.

Applications today do not have a way to distinguish between different classes of conditions that cause InvalidGrant, and therefore only can have a very generic way to handle this state, which leads to end user confusion and user experience dead ends in some of application flows.

For more details and description of scenarios, please see Improving CA Error Experience in Office.pptx

Requirements

1. Apps must be able to distinguish between several classes of InvalidGrant condition. See "API Changes" section for the detailed list.
2. Decouple complexity of various error conditions on the server from client apps. Server must retain capability to quickly iterate and add new authentication flows and conditions, without requiring client apps to be changed in any way.
3. Extensibility: provide a way for future classes of InvalidGrant condition to be communicated to apps without the need to service authentication libraries.

Solution

API Changes

MSALs will expose additional classification of InvalidGrant condition. This classification will be returned as a string, with the following meaning and recommended handling:

The way this string is returned is language specific. For example, if a language already throws InvalidGrant exception, this string could be an additional field in the exception class. Other languages may have different ways to achieve the same goal, depending on how errors and status are currently communicated to apps that consume MSALs.

It is possible that new classifications will be added in the future. Applications are expected to treat all unknown classifications as if though classification was not present (default handling).

Usage pattern example

This is a sequence of calls that an app might make to take advantage of classification. This hypothetical app downloads a set of documents from various cloud endpoints and displays document thumbnails in a list. For documents that cannot be downloaded, the app makes decision on how to paint the UI, depending on the classification of InteractionRequired condition. This is a very simplified example, written in pseudo code. It assumes that each document is downloaded from a different cloud endpoint that requires a different access token. This will, of course, be much more complicated in reality.

foreach (documentUrl in documentUrls) {
    try {
        authParams = getAuthParams()
        authParams.scope = getScopeFromUrl(documentUrl)
        authenticationToken = AcquireTokenSilently(authParams)
        document = downloadDocument(authenticationToken, documentUrl)
        showDocumentThumbnail(document)
    }
    catch (UserInteractionRequiredException exception) {
        switch (exception.classification) {
            case "basic_action":
                // Show the button that invokes AcquireTokenInteractively() 
                showFixItButton();
                break;
            case "additional_action":
                // Show a message that explains to the user that fixing the problem is more involved.
                showAdditionalActionMessage();
                // Show the button that invokes AcquireTokenInteractively() 
                showFixItButton();
                break;
            case "message_only":
                // Do nothing here. Skip documents that cannot be downloaded at this time.
                break;
            default:
                // Invoke default error handling routine that assumes no tokens can be issued, and no documents can be shown. 
                // Hide all thumbnails and show a button to fix the issue.
                hideAllDocuments();
                showSignInMessage();
                showFixItButton();
                break;
        }
    }
}

Protocol

List of all server suberror codes, as of 2019-06-04 can be found here.

Implementation of parsing and mapping

Not all values currently returned in suberror field in the protocol map to InvalidGrant classification that is expected to be returned to apps. Some of the values returned are needed for other features, and are internal implementation that should not be exposed to calling apps directly. MSALs will parse suberror field, and map values to one of classes expected to be returned to the calling app, if applicable. Mapping should be as follows:

Compatibility and versioning considerations

Depending on how particular MSALs choose to implement this feature, it could be either a breaking change, or an additive change. For example, adding a new field on an exception object would be an additive change, and adding a new exception type altogether would be a breaking change. Additive change is preferred, but is not required. When an app takes the new version of MSAL with this change, compatibility implications must be clearly documented.

Additional changes to the protocol must only be applied to clients that know how to handle them.

Next: To define exactly how to expose this in MSAL Java

Describe alternatives you've considered

N/A, above is a result of lengthy discussions.

Additional context

Details available here.

The azure-sdk-for-java project is trying to standardise on using Jackson as its JSON library of choice. Is it possible to discuss the possibility of this library also standardising on this library, or is Gson a set-in-stone decision now?

Hi,

Do you have an example for validating the idToken?

I have a token from the Authentication header like this: "Bearer XXXXXXXXX" and I would like to create a filter like the AADAuthenticationFilter from spring boot using the msal library but I'm not sure how can I validate the token from the client ID.

What I've seen is that I need to get the access token from my id token but how can I do that using the ConfidentialClientApplication class?

After that I can create my principal using the token information like in the samples but how can I validate my token?

Thanks!

My Azure AD has intergrated with a third-party IDP using SAML for sso, just like this: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-saml-idp
The third party IDP will finish the authentication. This solution is workable for web-based applications.
Now, i need to finish this authentication in a programmatic way. if i use ADAL or MSAL, Could i get an access token from Azure using username and password without interactive log-in? just like this: https://docs.microsoft.com/en-us/azure/active-directory/develop/scenario-desktop-acquire-token
My Azure AD do not store passwords, and i do not need sso, i jsut want to get access token in my code.

I run this demo
https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/samples/public-client/B2CFlow.java

CompletableFuture future = app.acquireToken(

            UserNamePasswordParameters.builder(
                    Collections.singleton(TestData.LAB_DEFAULT_B2C_SCOPE),
                    userName,
                    password.toCharArray()).build());

but what does TestData.LAB_DEFAULT_B2C_SCOPE mean? where can i get this value in azure portal?

Return value for acquireTokenSilent should never be null. It should either be:

• IAuthenticationResult in case of successful request
• Exception is thrown if there is a cache miss or STS returns an error (MsalUiRequiredException)

v2 endpoint returns verification_uri instead of verification_url

Confidential clients will support previously signed client assertions as well as a collection of claims with an accompanying certificate so that the user can specify exactly what claims should be signed when creating the JWT.

Signed assertions will simply be passed along to the endpoint without any modification. It is expected to be a base 64 encoded JWT.

Set a standard for cache access - Example: How long it takes to make cache access? Set a benchmark and see if it gets worse.