Enhance Secret Service Authorization Capabilities

[weberjm]

As an integration user or component developer, I want to be able to handle standard authorization flows without requiring custom code development. To enable this, the Secret Service should be expanded to handle more flows, in addition to its already available OAuth flows.

Tasks (including maintenance):

• Research and diagram common auth flows and specific flows from our connected solutions
• Determine how to abstract flows to reusable solutions for flow-manager
• See which flow types need a preprocessor for storing Secrets
• Update Secret Service encryption layer to no longer use deprecated library
• Analyze the problem of decrypting and re-encrypting secrets

[winklerj]

Additionally while looking at Amazon's OAuth2 authentication https://github.com/amzn/selling-partner-api-docs/blob/main/guides/en-US/developer-guide/SellingPartnerApiDeveloperGuide.md#step-3-amazon-sends-you-the-authorization-information it looks like it varies slightly from what's currently available. To make it work there are some slight adjustments to be made configurable.

• At a minimum be able to configure the expected authorization code parameter. Right now it is hard coded to code. As an example Amazon uses spapi_oauth_code. Ideally you can configure the expected parameter name for all the required parameters, but default to their current parameter keys.
• Save additional parameters sent to the callback service. As an example shopify sends the shop, host and hmac. Amazon sends selling_partner_id and mws_auth_token.

[weberjm]

@winklerj It's always fun when every application decides to deviate from the standards, even when they are officially just proposed...

The spec says that only code and state parameters may be provided, and any other parameters must be ignored by the client. https://datatracker.ietf.org/doc/html/rfc6749#section-4.1.2

I think the first bullet point would be fairly easy to implement. Regarding the second, I'm not sure what we are then expected to do with unrecognized parameters. Where would we save them, and how would we work with them afterwards? Based on the names, I am guessing that the hmac parameter would become the HMAC private key? Or is it actually an HMAC hash which one could use to verify provenance of the message?

[winklerj]

@weberjm I agree what Amazon has isn't standard, but I guess you can throw your weight around when you own a large chunk of the market.

For the second one solution I had was appending the additional parameters to the success url. I realize this could open an application to all kinds of additional parameters being sent on the success URL. So, maybe as part of the auth client config you would specify which parameters are allowed to be forwarded to the successUrl?

I'm not as concerned about the Shopify values being stored and having the secret service validate the HMAC. Those are temporary values whereas the Amazon parameters are meant to be reused later. If they are forwarded on to the successUrl the external application can handle validation or storing of additional parameters. It would be a nice to have to store the additional parameters (which were specified as allowed by the auth client config) instead of just appending them to the successUrl

[winklerj]

I noticed the secret service README.md and unit tests reference a mappings object, but there is nothing that implements logic for handling mappings. Possibly this was intended to serve my first bullet above.

Readme section: https://github.com/openintegrationhub/openintegrationhub/tree/master/services/secret-service#auth-clients
Example test: https://github.com/openintegrationhub/openintegrationhub/blob/master/services/secret-service/src/route/auth-clients/index.spec.js#L84

[russojrv-zz]

I see that in the secret service when we handle the callback, it would be useful if we could configure the properties that we get from the authorize endpoint. For example, in case of slack, See the alternate response , the access token comes in a wrap object inside "authed_user" property. In our framework, we just try to get the token from the access_token root level property.
https://github.com/openintegrationhub/openintegrationhub/blob/master/services/secret-service/src/route/callback/handle-oauth2.js#L55. We should think in a way to be able to configure the path of the parameters in the oauth requests in this case.

[RobinBrinkmann]

we will divide this issue in sub-issues (@russojrv)

[weberjm]

The open topics from this "epic" all have their own issues which will now be worked separately. This issue will now be closed in favor of the separate issues.