Closed hdjustice closed 3 months ago
Current MuleSoft Integration uses a client_id
and client_secret
.
We use OAuth 2.0 when integrating with Lighthouse. One example I found was the Benefits Claims Service that uses this, so that should be helpful. Another example is the Salesforce::Service
that authenticates with salesforce using a jwt.
It looks like Okta has a Gem that could be helpful, although I don't know if it works with okta-gov specifically.
We will need to update any vcr cassettes used in specs that are calling the caregiver endpoint. This will increase scope of implementing the change.
I'm waiting to hear confirmation, but I'm guessing we will use the Client Credentials Grant flow. More info for using that with Okta here.
Created the following tickets to implement these changes:
Background
Mule DTC is planning to implement OAuth2.0 for securing APIs deployed in Mule GovCloud.
Currently the Mule APIs are secured with Client ID/Client Secret mechanism and want to move to OAuth2.0 (using Okta as Identity Provider). VA application authenticates against Mulesoft API. Today we use appid and apptoken to perform the authentication. Mule team has determined that moving to Oauth 2.0 will enhance security. So this is just a more secure method to authenticate to gain access to the API.
Will likely need to set up a new backend integration with dtc-va.okta-gov.com endpoint, if it doesn’t already exist https://dtc-va.okta-gov.com/oauth2/ause1x1h6Zit9ziQL0j6/v1/token?scope=read&grant_type=client_credentials
This ticket is for exploration on what tasks are needed to complete this change, including confirming whether the dtc-va.okta-gov.com endpoint exists in VA.gov integrations today.
Tasks
Acceptance Criteria