Glen Mazza's Weblog

For the two Salesforce OAuth2 flows discussed in my earlier blog post, namely the JWT bearer token and username/password flows, I've created a sample Spring Boot app on Github. This app will obtain access tokens using the flow you configure and make a sample call to Salesforce's standard "Account" resource. Note both these server-to-server flows assume a hardcoded single resource owner for all API calls. (For clients handling multiple users logging in and authorizing calls, Salesforce's Web Server Flow is more appropriate, there are some links at the bottom for information on this flow.)

To run the sample, first create an application.properties file in the resources folder with the configuration necessary for the flow you are using (there is a template file in that folder specifying what is needed for each flow type, with the earlier blog post providing instructions on how to obtain these values). The sample's SalesforceOAuth2Config class reads that configuration, and will halt on startup with informational messages if anything needed is missing. The app can be run from an IDE like IntelliJ or command-line via gradle bootRun, and it will make a sample call retrieving one Salesforce Account object every 30 seconds until halted.

To create the app, I used Spring's Initialzr with the latest Spring Boot release version and Java 11, and added the Spring Web, Spring Reactive Web, and OAuth2 Client dependencies. During development I also brought in a few extra libraries listed in the build.gradle. The Username/Password flow is supported out of the box by Spring, but the JWT bearer token flow requires some extra classes that I implemented following Spring's source code for their standard password and client grant flows. The files are commented to aid in understanding this flow:

• SalesforceJwtBearerOAuth2AuthorizedClientProvider - For each outgoing request to a resource server, checks if the JWT Bearer Token method is being used for access tokens and also if an authorized client (i.e., one with a valid access token) is already available. If yes and no, respectively, initiates the process to obtain a new access token to use with the resource API call.
• OAuth2SalesforceJwtBearerGrantRequest - created by above class, it holds the information necessary to create the JWT bearer token for making an access token request.
• OAuth2SalesforceJwtBearerGrantRequestEntityConverter - Constructs the JWT bearer token
• SalesforceJwtBearerTokenResponseClient - Uses the JWT Bearer token created by the above class to obtain a new access token from the authorization server.

What happens when access tokens expire? The WebClient call in SalesforceService has a retry(1) setting that allows one additional call to the resource server in case of an error such as using an expired access token. In such cases, for the first call, the failure handler in SalesforceOAuth2Config removes the authorized client instance (which has the invalid access token) from memory. For the retry call, SalesforceJwtBearerOAuth2AuthorizedClientProvider notes that there is not an authorized client instance anymore so proceeds to obtain a new access token to allow the second call to proceed. This functionality can be verified by revoking the access token from either Salesforce Setup's Session Management screen or from Connected Apps usage, and making a subsequent resource API call, it should seamlessly provide the data. Code breakpoints can also be used to confirm another access token was requested.

Additional Resources

• OAuth 2.0 Client - official Spring documentation
• Spring WebClient – GET, PUT, POST, DELETE examples - Efficient read for learning more about WebClient.
• Spring 5 WebClient and WebTestClient Tutorial with Examples
• Salesforce Username/Password Flow Example - Very helpful in creating the Username-Password flow in this sample.
• For implementing Web Server Flow, this Salesforce video and this Baeldung article can provide some starting guidance.