Where should auth credentials be stored (e.g oauth2 access token)?

[giorgosera]

Hey there, I'm a bit confused about authDefs and secrets and where should I keep auth credentials for function invocation.

Here's my use case:

• I need to run multiple actions in a workflow. For my use case actions represent function invocations of 3rd party app APIs such as slack, typeform etc.
• For each of those services I have already went through the auth process and acquired the individual access tokens to call those APIs
• So let's say I have two actions one for invoking a 3rd party API A and another one for3rd party API B.

Based on my current understanding there are two options for storing the auth credentials with Serverless DSL:

• Authdef: but authdef doesn't seem to have a place for an access token to be stored (unless this is what subjectToken is)
• Secrets: use workflow secrets and reference them functionDef arguments. As the documentation says these can be used to store OAuth tokens.

Questions:

1. Which of these options is valid? Or both are invalid and there's another way which I'm missing?
2. Also, if secrets are the correct option then what is auth def used for?

I can see that there was another discussion on this and someonee suggested here to separate credentials and auth properties.

This suggestion looks very close to what I'm trying to achieve. Any chance this is part of the spec now?

Thanks

[ricardozanini]

Hi @giorgosera!

You can use secrets to store any value and retrieve it via expressions to call your functions later in the workflow.

In the OAuth2 flow, if I understood your question correctly, to me it seems that your underneath implementation should use the auth properties to acquire the token and pass it to the function as it calls it.

In the OpenAPI definition, you will see that each operation describes how to properly call it security-wise. So the workflow author shouldn't need to define yet another argument to call the function. Every information needed is supposed to be there.

An example:

{
     "functions": [{ "operation": "withauthopenapi.yaml#securedOperation", "name": "securedFunction", 
     "authRef": { // OAuth2 definition, with the token via $SECRETS example:
         "username": "alice",
         "password": "{ $SECRET.mypassword }"
     }
      }],
     "states": [{
         "type": "operation",
         "actions": [
         {
           "functionRef": {
             "refName": "securedFunction",
             "arguments": {
               "arg1": "${ .arg1 }"
             }
          }
        }
     }]
}

The authRef will replace any OpenAPI file definition, so you can override the way you call your functions there. If it's not defined, I assume the underneath implementation should take what is described in the OpenAPI as the source of truth.

The authRef for function calls is a new feature in the yet-to-be-released version 0.9, so the OpenAPI definition should have this info and won't be overrided by the workflow definition, nor use the secrets.

[giorgosera]

Thanks @ricardozanini! Makes sense.

I'm not sure I understand your comment:

But I wouldn't since it should not be the workflow author responsible for dealing with credentials.

Maybe it is still not clear to me what the boundaries between the workflow author and the runtime are but I'd assume that the workflow author can populate the authRef for the functions and the $SECRETS (just the names) that are needed. Then the runtime should be responsible to replace the secrets with the values at runtime. Is this correct?

[ricardozanini]

@giorgosera, this is correct. But I'd let the underneath runtime to take the information from the openapi specification and enhance the request.

You can use the authRef and SECRETS to push them as arguments, but I think this is not a domain/business problem.

Take this as an example:

  securitySchemes:
    app_id:
      type: apiKey
      description: "API key to authorize requests. (If you don't have an API key, get one at https://openweathermap.org/. See https://idratherbewriting.com/learnapidoc/docapis_get_auth_keys.html for details.)"
      name: appid
      in: query

The appid should be added in the querystring of each request. Then, in the workflow definition if you'd call it from your actions:

{
     "functions": [{ "operation": "weather.yaml#CurrentWeatherData", "name": "weatherData"}],
     "states": [{
         "type": "operation",
         "actions": [
         {
           "functionRef": {
             "refName": "securedFunction",
             "arguments": {
               "appid": "${ $SECRETS.appid }"
               "arg1": "${}",
               "arg2": "${}",
             }
          }
        }
     }]
}

Imagine having to do this for every call?

Then, what if your runtime already knows that it will call this function and already knows about the OpenAPI specification? Then, the runtime can have an external configuration that would inject this info for you as it makes the request. You don't need to provide it every time.

I'm trying to say that even if the spec allows it (and it should), your runtime can be smart and figure that alone based on the openapi definition. Does that make more sense now?

[giorgosera]

Ok that clears up a lot of things. I was under the impression that the runtime cannot make any assumptions and that the DSL should explicitly instruct the runtime. But what you said makes sense and takes advantage of open standards like OpenAPI which I believe is the philosophy of Serverless DSL.

This makes me wonder though. Since we're using custom functions what is more idiomatic to SW?

• Create our own "OpenAPI" spec resource and make it accessible to the runtime via the operation property?
• Or use function.metadata to specify ?

Does this makes sense?

[ricardozanini]

Well, for custom you can do whatever you want, but I'd say to abuse the operation attribute if possible. If it's a custom generic function that you think others would use, why not create an extension?

See in Kogito: https://kiegroup.github.io/kogito-docs/serverlessworkflow/latest/service-orchestration/configuring-openapi-services-endpoints.html

They extended the OpenAPI operation with a supportable structure from the spec pov. :)

[giorgosera]

Wow that's fantastic! Thanks for sharing.

[cdavernas]

Based on my current understanding there are two options for storing the auth credentials with Serverless DSL:

• Authdef: but authdef doesn't seem to have a place for an access token to be stored (unless this is what subjectToken is)

If you want to store a token directly, you can:

1. Use the bearer authentication scheme:

...
auth:
- name: MyBearerAuth
  scheme: bearer
  properties:
     token: 'MyJwtToken'
...

2. Use secrets, directly in runtime expressions ($SECRETS.MYSECRET.TOKEN), or by setting the properties of an AuthDef to the name of the secret that contains the expected data (i.e. { "token": "MyToken" })
3. Do it properly: use OAUTH2, with the client_credentials flow, or, in your case, using the token_exchange flow to impersonate a user using its token:

...
auth:
- name: MyOAUTH2
  scheme: oauth2
  properties:
    authority: http://myauthority.com
    grant_type: urn:ietf:params:oauth:grant-type:token-exchange
    subject_token: "USER_ACCESS_TOKEN"
...

[giorgosera]

thanks @cdavernas it makes sense.

Unfortunately, not all auth servers support the exchange token grant so it'll have to be the solution with the secrets.

Appreciate everyone's help in this 🙏