Add additional authority endpoints to OAUTH2

[cdavernas]

What would you like to be added:
Add a new property to OAUTH2 authentication, used to define additional token endpoints in order to address serverlessworkflow/synapse#342

Why is this needed:
As explained by @jaliyaudagedara in serverlessworkflow/synapse#342, this is a requirement for many librairies when facing authority mismatch

[cdavernas]

@ricardozanini @JBBianchi @matthias-pichler-warrify @fjtirado What do you guys think? Can I proceed with it and open a PR?

[matthias-pichler]

Is this in the case where the openId connect configuration lives on a different domain than e.g. the token endpoint?

[cdavernas]

Yes, exactly!

[matthias-pichler]

Ok got it. What would a proposed solution look like? Because I guess making authority an array would mess up the openId discovery right?

On a related note: since OpenID Connect and OAuth2 are separate specifications and many OAuth APIs don't have an OIDC config shouldn't there be a way to specify e.g the token uri directly? And from the fields client.id and client.secret I guess that only the client_credentials flow is supported: what about other flows? (e.g. the legacy password flow)

Would it make sense to either:

• add a new openid auth type? (probably overkill)
• or extend the oauth2 auth type to allow more flows and specification fields (like tokenUri) that would normally come from an openId config?

[matthias-pichler]

I am actually kind of struggling with the lacking support for oauth right now.

I think a solution should at least cover the following cases:

Open ID Connect

one can definitely specify a well-known uri to a open id config.

document: {}
use:
  authentications:
    exampleOIDC:
      oauth2:
        openIdConnect: https://example.com/.well-known/openid-configuration
        trustedAuthorities:
          - example.net
        grant: client-credentials
        client:
          id: workflow-runtime
          secret: "**********"
       # audience, scopes, etc

Question @cdavernas is the domain enough to whitelist additional endpoints?

Token endpoint

document: {}
use:
  authentications:
    exampleOIDC:
      oauth2:
        tokenEndpoint: https://example.com/oauth2/token
        grant: client-credentials
        client:
          id: workflow-runtime
          secret: "**********"
       # audience, scopes, etc

Open Questions

1. Content-Type: RFC 6749 states that the access token request body should be application/x-www-form-urlencoded encoded, however JSON is also extremely common. Should this be configurable?
2. Client Authentication: RFC 6749 states that the client_id and client_secret can be sent via Basic authentication (client_secret_basic ) or in the request body (Section 2.3.1) (client_secret_post ). Some APIs only support one way: should this be configurable? What about rarer ways of client authentication like client_secret_jwt and private_key_jwt?
3. Grant types: Should we support other grant types as well? Specifically the password grant

[fjtirado]

@matthias-pichler-warrify
I would say that by default, if nothing is specified, for 1. and 2. both should be suppoted. Meaning that, unless otherwise specified, the runtime should accept both x-www-form-urlencoded and application/json and the client_id and client_secret can both be on Basic header or in the request body. If we are going to configure something on the file, it should be to restrict it.
Regarding grant types, I think the only additional one that we should support is the password grant.

[matthias-pichler]

Meaning that, unless otherwise specified, the runtime should accept both x-www-form-urlencoded and application/json and the client_id and client_secret can both be on Basic header or in the request body. If we are going to configure something on the file, it should be to restrict it.

Yeah the issue is that I don't think the runtime has a way to figure out which one is supported by any given endpoint. So I think the author has to specify which is desired. So my question is what should this config look like?

For example Amazon Cognito support both client_secret_basic and client_secret_post authentication but only application/x-www-form-urlencoded bodies.

Auth0 supports both application/x-www-form-urlencoded and application/json bodies but only client_secret_post authentication.

and there exists basically any combination imaginable out there

[cdavernas]

And from the fields client.id and client.secret I guess that only the client_credentials flow is supported: what about other flows? (e.g. the legacy password flow)

In my personal and professional use cases, I actually use both client_credentials and token_exchange, so I'd say those two, at the very least, should be supported.

or extend the oauth2 auth type to allow more flows and specification fields (like tokenUri) that would normally come from an openId config?

Good catch! Yes, we should probably update the oauth2 authentication, or as suggested, create a new openid one.

Question @cdavernas is the domain enough to whitelist additional endpoints?

I believe it should, yes, though I never had the need to whitelist, so the question would be better addressed to @jaliyaudagedara!

Content-Type: RFC 6749 states that the access token request body should be application/x-www-form-urlencoded encoded, however JSON is also extremely common. Should this be configurable?

I believe it should, yes.

Authorization: RFC 6749 states that the client_id and client_secret can be sent via Basic authentication or in the request body (Section 2.3.1). Some APIs only support one way: should this be configurable?

Yes, IMHO it should be configurable too!

Grant types: Should we support other grant types as well? Specifically the password grant

We probably should support the legacy password grant type, indeed. Others are useless in the workflow context, AFAIK (ex: implicit)