<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Okta Classic Engine

MatthewH.10249 (State of Iowa) asked a question.

What are the required scopes needed for api_v1_org_email_bounces_remove-list?

I've created a Delegated Workflow that calls the "/api/v1/org/email/bounces/remove-list" API endpoint to help clear bounced or blocked email addresses in Okta. I've been doing this via Postman with no issues so I decided to create a delegated workflow so others like Help Desk staff can take care of these when the pop up.

https://support.okta.com/help/s/article/Troubleshooting-EMail-Deliverability?language=en_US

 

When I run the Workflow "Okta Custom API Action" card in the Workflow it fails with the following error.

error="insufficient_scope", error_description="The access token provided does not contain the required scopes.", resource="api_v1_org_email_bounces_remove-list""

I know this runs under the context of the "Okta Workflows OAuth (OpenID)" app but I don't know what "scope" to grant to that app in order to get past this issue.

 

FYI - I am able via a "API Connection Post" card to make the API call successfully but that uses an API Token in the request header. I don't want to use this card because this Workflow will not run that often and thus the API Token will expire and require someone to manually generate a new token and modify the Workflow which is not desirable. I could create some sort of token keep alive but I'm hoping that there will not be necessary.


  • TimL.58332 (Workflows)

    @MatthewH.10249 (State of Iowa)​ 

     

    So this is a pretty tricky one. Workflows "Okta" connection is not going to support doing this out of the box as it leverages the scope (okta.orgs.manage) and the Okta connection will not request this scope.

     

    Additionally, okta.orgs.manage isn't a scope listed in the Scopes column of Applications.

     

    That being said what you can do is the following which I just got through testing and was successful:

     

    (Note: I only performed this process once so the following instructions might be a tad off but should be mostly accurate)

     

    Create an OIDC Web App:

     

    1) Navigate to Applications > Applications and choose "Create App Integration"

    2) Select OIDC > Web Application

    3) Leave it as Authorization code & Select Refresh Token

    3) Set redirect URI:

    https://oauth.workflows.oktapreview.com/oauth/httpfunctions/cb

    https://oauth.workflows.okta.com/oauth/httpfunctions/cb

    4) Assign your admin to the app (and/or potentially the service account)

     

     

    Grant the App the scope:

     

    1) Create an API Token

    2) Create a API Connector connection (Custom) with header: Authorization value: SSWS <token value>

    3) Create a new flow (This is a one time use flow)

    4) Add a - Object Construct card and add the following pairs:

     

    scopeId : okta.orgs.manage

    issuer : https://<your Okta tenant domain>.okta(preview).com

    5) Add a compose card

    https://<yourdomain>.okta(preview).com/api/v1/apps/<webAppID>/grants

    6) Add an API Connector RAW card

    7) Set the Auth to the API Token connection

    8) Set the Method to POST

    9) Drag the created object in step 4 to the Body

    10) Run the flow.

     

    This is going to grant okta.orgs.manage as an allowed scope for the application.

     

    Setup an API Connector Oauth connection:

     

    1) Create a new API connector connection with the type being Oauth

    2) Obtain the clientId/Secret from the Web App

    3) Set the scope to: offline_access okta.orgs.manage

    4) Token/Auth paths by default are:

    https://<yourOktaDomain>/oauth2/v1/authorize

    https://<yourOktaDomain>/oauth2/v1/token

     

    Since you are logged in it should just leverage your user and automatically consent.

     

    You should now be able to test hitting the email endpoint with the Oauth connection.

    Expand Post
    Selected as Best
  • TimL.58332 (Workflows)

    @MatthewH.10249 (State of Iowa)​ 

     

    So this is a pretty tricky one. Workflows "Okta" connection is not going to support doing this out of the box as it leverages the scope (okta.orgs.manage) and the Okta connection will not request this scope.

     

    Additionally, okta.orgs.manage isn't a scope listed in the Scopes column of Applications.

     

    That being said what you can do is the following which I just got through testing and was successful:

     

    (Note: I only performed this process once so the following instructions might be a tad off but should be mostly accurate)

     

    Create an OIDC Web App:

     

    1) Navigate to Applications > Applications and choose "Create App Integration"

    2) Select OIDC > Web Application

    3) Leave it as Authorization code & Select Refresh Token

    3) Set redirect URI:

    https://oauth.workflows.oktapreview.com/oauth/httpfunctions/cb

    https://oauth.workflows.okta.com/oauth/httpfunctions/cb

    4) Assign your admin to the app (and/or potentially the service account)

     

     

    Grant the App the scope:

     

    1) Create an API Token

    2) Create a API Connector connection (Custom) with header: Authorization value: SSWS <token value>

    3) Create a new flow (This is a one time use flow)

    4) Add a - Object Construct card and add the following pairs:

     

    scopeId : okta.orgs.manage

    issuer : https://<your Okta tenant domain>.okta(preview).com

    5) Add a compose card

    https://<yourdomain>.okta(preview).com/api/v1/apps/<webAppID>/grants

    6) Add an API Connector RAW card

    7) Set the Auth to the API Token connection

    8) Set the Method to POST

    9) Drag the created object in step 4 to the Body

    10) Run the flow.

     

    This is going to grant okta.orgs.manage as an allowed scope for the application.

     

    Setup an API Connector Oauth connection:

     

    1) Create a new API connector connection with the type being Oauth

    2) Obtain the clientId/Secret from the Web App

    3) Set the scope to: offline_access okta.orgs.manage

    4) Token/Auth paths by default are:

    https://<yourOktaDomain>/oauth2/v1/authorize

    https://<yourOktaDomain>/oauth2/v1/token

     

    Since you are logged in it should just leverage your user and automatically consent.

     

    You should now be able to test hitting the email endpoint with the Oauth connection.

    Expand Post
    Selected as Best
    • MatthewH.10249 (State of Iowa)

      @TimL.58332 (Workflows)​ Thanks for all the instructions but I'm not able to complete them all. I was able to create and run the "Grant the App the scope:" Workflow but I'm getting an error when I try the final steps "Setup an API Connector Oauth connection:". After I enter all the connection details and press the "create" button I get a new window that says "Not Found... We couldn't find what you were looking for.". I got the same error when I tried our ...okta.com domain and our custom domain. Ideas?

      Expand Post
  • SarahS.89561 (Customer)

    @TimL.58332 (Workflows)​ I'm having the exact same issue as Matthew, any chance on an update of what's wrong with the setup

  • MatthewH.10249 (State of Iowa)

    @SarahS.89561 (Customer)​ not sure if this is your problem but I had assigned a Service Account to the new "OIDC Web App" Tim had me create in the steps above but then I tried to create the Workflow oAuth connection using my personal account which was not assigned to the "OIDC Web App". BIG thanks to @User15905896560008893663 (Vendor Management)​ @aj.ahrens1.547437272561944E12 (Okta, Inc.)​ who helped me figure that out. While embarrassing, I'm happy that I was able to create the connection and now I can leverage this new way to hit scopes I could not before. Thanks again @TimL.58332 (Workflows)​!

    Expand Post
  • SarahS.89561 (Customer)

    @MatthewH.10249 (State of Iowa)​ Would you mind spelling it out for me, at the moment I'm using an svc-user@ account with org admin rights and then poking the api token into the authorize header, this works like a charm and I have a flow which runs once a week and reads a user to keep the api token alive

     

    I don't really want to associate any of this with my account, what happens if I get run over by a bus 😁

     

    Basically, this is going to be a delegated workflow (delegated to our Service Desk) and I would like the backend to have the least privileges possible

     

    Hope that makes sense and any further help would be appreciated

     

    Regards

    Sarah

    Expand Post
    • MatthewH.10249 (State of Iowa)

      @Sarah Spittle, I too used a service account but the issue I was having was that I had not used the service account when it came time to create the oAuth connection. I was using my personal user account which was not assigned to the new OIDC app that was created and scoped for the claims that were not accessible before.

      Make sure your service account is tied to the OIDC app and make sure you are logged in as the service account when you create the oAuth connection and it should work.

      Lastly, once you successfully create the aAuth connection and then use it in your Workflow, do not set the Authorization Header with an API token because the fact that you are using the oAuth with the service account credentials will automatically give you the claims you have set on the OIDC app. Again, an API token should NOT be used for this custom oAuth connection in your Workflow.
      Expand Post
      • SarahS.89561 (Customer)

        Hi Matthew

        I can't sign in with the user account in Workflow because it's not a Super Admin so won't let me assign workflows to it

        Am I missing something?

        Think I might have been hit by that bus 😂

        Regards
        *Sarah Spittle *

        *Systems Integration and Automation Engineer Citizens Advice
        <
        http://www.citizensadvice.org.uk/>*
        Mobile: 07471950092

        We give people the knowledge and confidence they need to find their way
        forward - whoever they are, and whatever their problem. For everyone, for
        over 80 years.
        Expand Post
      • MatthewH.10249 (State of Iowa)

        @Sarah Spittle (Customer), The only thing you need to use the Service Account for is the "Setup an API Connector Oauth connection" steps that @Tim LaBorn (Workflows). While the service account I'm using does have the Super Admin role, a lesser role should be fine. Once the connector is created use your own personal admin account to create the Workflow that will leverage the Oauth connection via an API Connector card.
        Expand Post
This question is closed.
Loading
What are the required scopes needed for api_v1_org_email_bounces_remove-list?