Expand my Community achievements bar.

SOLVED

Adobe credentials for standalone actions execution

Avatar

Community Advisor

We successfully implemented a Firefly App that fetches data from an external API and writes data into Adobe Analytics (using the old API 1.4). This works perfekt since the action can use the UI-User credentials (read from params) like this:

    const resHeaders = {
      "authorization": params.__ow_headers["authorization"],
      "x-api-key": params.__ow_headers["x-api-key"],
      "w-gw-ims-org-id": params.__ow_headers["w-gw-ims-org-id"],
      "x-api-key": params.__ow_headers["x-api-key"]
    }     

 but where does the action gets the credentials if there is no UI providing the params? what "user/key" does it have to execute requests against Analytics API? or can I somewhere add credentials to manually set the desired values?
Thanks a lot for the support!

Topics

Topics help categorize Community content and increase your ability to discover relevant content.

1 Accepted Solution

Avatar

Correct answer by
Employee

Hi @Urs_Boller , first of all it would be good to identify whether your app is an SPA or headless, as described in the Security Overview . I assume you have the `require-adobe-auth` flag set to true for your actions.

If it is an SPA, the user token must be passed from the Adobe Experience Cloud (ExC) Shell, specific to the user session you are logged in.

If it is a headless app, you need to pass a service token which is obtained with the JWT auth flow.

You could also use a user token in a headless app to call the backend services, as long as it has valid authorization and scopes. However, you can not use a service token to call backend services of an SPA, because the session has to be tied to a specific user.

Please let me know if something needs further clarification.

View solution in original post

4 Replies

Avatar

Correct answer by
Employee

Hi @Urs_Boller , first of all it would be good to identify whether your app is an SPA or headless, as described in the Security Overview . I assume you have the `require-adobe-auth` flag set to true for your actions.

If it is an SPA, the user token must be passed from the Adobe Experience Cloud (ExC) Shell, specific to the user session you are logged in.

If it is a headless app, you need to pass a service token which is obtained with the JWT auth flow.

You could also use a user token in a headless app to call the backend services, as long as it has valid authorization and scopes. However, you can not use a service token to call backend services of an SPA, because the session has to be tied to a specific user.

Please let me know if something needs further clarification.

Avatar

Community Advisor

Hi @duypnguyen thanks for the details.

Yes, action is secured and I am able to hand over credentials within the SPA, action gets executed successfully using my login credentials.
but in the end, we want the action to run as headless (scheduled execution), where there is no login. Do you have any example for "pass a service token which is obtained with the JWT auth flow" in the Firefly environment?

Avatar

Employee

Hi @Urs_Boller, in that case you first need to remove the web-src/ folder to make your app headless instead of SPA, so that JWT token can be validated.

 

aio app delete web-assets

 

To test the token, you could retrieve it from I/O Console, under "Generate JWT token" in your project, and pass it in the request header to your action, e.g. `Authorization: Bearer ey1234567890....`.

To have the token generation in action code, you could leverage the Adobe IMS SDK . Please note that, it's better not to expose your action as a web action in this case, because then anyone can access your data. What would make sense for this authentication is a cron job which runs at interval to import data from Analytics, for example. You can use the Alarms package to set up this cron job.

Avatar

Community Advisor
Hi @duypnguyen thanks for explanation. Yes, we are fully aware that using a webservice makes to action possible to run for everybody (but in this case this is ok). We are just looking for a way to have an action both accessible in the UI as well as running with the alarm package. so we will try to use a service account within the action whenever it runs. the action will only do something if it has not run already or if there has been an error in the last run. so just in case the action has run successfully and a user triggers the action in the UI (which might only be possible for admins), it would do nothing at all