epakh (epakh) asked a question.
Hello!
We have our own NestJs service that we have as an application in Okta that users use Okta to log into.
I am trying to create a workflow where when a user's profile is changed in Okta, we call to our external service to update the user in our own database.
I have this workflow working using event triggers that lead to an API Connector call, however, the API Connection I have is set up with no authentication.
I tried following this article: https://support.okta.com/help/s/article/How-to-Authenticate-with-HTTP-Cards-Okta-Workflows?language=en_US Step 7 - OAuth but I don't have an endpoint on my own external service for an "Access Token". I have the information for all the other fields, but the Access Token endpoint we use is an Okta endpoint (as we authenticate through Okta). I've tried putting our okta endpoint in `https://trevorprojectsandbox.oktapreview.com/oauth2/{aus..}/v1/token` but I get directed to a `https://trevorprojectsandbox.workflows.oktapreview.com/app/oauth/httpfunctions/...` Not Found page (I'm guessing since I added that URL as my Redirect URI on our App. I've also tried putting it as our application URL or localhost but those fail in the same way.
Am I missing something? Any advice on how to set this up so there's authentication from our workflow to our service endpoint?
Thanks in advance!
@epakh (epakh) -- Hello,
From going over your scenario it is really broken up into 2 core parts and the first part you seem to have figured out.
Part one - A monitored event occurs that you "may" want to take action against. In this instance you are monitoring for changed User Profile attributes. And if the changedAttribute meets your criteria you want to perform an action (Part two).
Part two - You have confirmed an event occurred that met your criteria and now you want to take an action. Based on the description there is some third-party service you want to update. One thing to keep in mind is Workflows is a "Client" in this scenario. That third-party service MUST have an externally accessible web-based API that Workflows can reach. The two most common API types are REST and SOAP (in that order). The Vendor should have specific documentation on how to Authenticate to their service and full documentation on how to perform actions against the available endpoints. If the vendor doesn't have an externally accessible endpoint or documentation on how to leverage there endpoint this isn't a viable use case.
To elaborate further. You indicated you want to update your "internal database". Which means there needs to be an Endpoint Workflows can reach. POST data to in a specific format. That endpoint then needs to be able to ingest that information, proeccess it, then establish a connection to the Database and use the Database's required process for making changes. This is the same idea as having a Web Server backed by a Database. The Webserver is the API endpoint with the logic to process the inputs and then communicate to and update the Database all initiated by a Client (likely a web browser).
Let me know if you need any clarification.
@TimL.58332 (Workflows) Thanks for the quick response, Tim! You are correct in Part one - and that I have it figured out. And Part Two, the functionality is correct. One thing I need to clarify is you said: "That third-party service MUST have an externally accessible web-based API that Workflows can reach"
In this case, our own NestJs service IS the third-party service we're referring to, aka, there's no "specific documentation on how to authenticate to their service" as it is our own service. I have a Users HTTP PATCH endpoint I added to our service and it works correctly when there is No authentication, my question is how do I add authentication.
It's our own service and users log in using Okta, the same Okta where I'm adding this workflow. So when I follow the steps here https://support.okta.com/help/s/article/How-to-Authenticate-with-HTTP-Cards-Okta-Workflows?language=en_US about adding OAuth to our connection to our service, it asks for an Access Token endpoint for our service. However, our service uses Okta for access tokens.
My question is how I can add authentication to this endpoint to protect the PATCH endpoint I added to our service that we're writing from Okta Workflows from, as the guide I linked doesn't seem to work if it's our own, Okta-Authenticated service I'm connecting to.
Tricky scenario, I know 😅 Thanks again!
(Had to post twice since I accidentally wrote in as an answer instead of a reply)
@epakh (epakh)
>My question is how I can add authentication to this endpoint to protect the PATCH endpoint I added to our service that we're writing from Okta Workflows from, as the guide I linked doesn't seem to work if it's our own, Okta-Authenticated service I'm connecting to.
You would need to program this in on the endpoint (server) side. The endpoint side is responsible for implementing the means to authenticate and the means to handle information that is authorized to be passed in. You definitely do not want a publicly exposed endpoint that has no authentication requirements that writes data into your environment.
Workflows is just a client. Its the same idea as having a Web client, an FTP client, or any other type of client. You don't add authentication to a client you utilize the client to authenticate to a server using one or more of the available authentication mechanisms the server provides. As far as Workflows is concerned Authentication is optional but definitely recommend. Otherwise, ANY client could communicate to the endpoint and potentially make changes endpoint (server).
Workflows communicates to a server over HTTPS and can user a variety of HTTP Methods with the typical CRUD ones being the most common (PUT GET POST DELETE). The Server must have an externally accessible address and allow communication over port 443.
The KB you linked: https://support.okta.com/help/s/article/How-to-Authenticate-with-HTTP-Cards-Okta-Workflows?language=en_US
Is discussing the built-in authentication methods that the Workflows client natively supports when communicating with a third-party endpoint because these are all very common implementations for Auth on endpoints (servers).