[Actions] Add RESTful OAuth support for action types by adding new SO for access/refresh token info storage.

[YulNaumenko]

Based on the investigation done in the issue,
we were planning to use a common storage with the problem for tls/ssl, but then we found out that this is a different tasks and should be implemented independently.
From this point, we decided to provide a new SO to store the grant info for all OAuth connections.
There is a couple of thoughts from @pmuellr:
Presumably it would be keyed off the connector id. Which means after a connector is deleted, we should also delete the grant info SO.
We could do this specifically in the connector delete logic - not sure if there's a reason why we would want to keep an old version around.
What happens if a user switches from user/pass to OAuth then back to user/pass then back to OAuth - should we keep all the OAuth info around? Seems like we probably would.

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[gmmorris]

A couple of questions:

1. Could these fields be added to the Connector SOs rather than a separate SO?
2. Are there security related concerns to storing OAuth tokens? (Perhaps we should include @elastic/kibana-security in this discussion)

[legrego]

Perhaps we should include @elastic/kibana-security in this discussion

Thanks for the ping!

It's not my place to dictate process, but I think an RFC would be appropriate here. I have a very high level understanding of what we're trying to do, so having a detailed design doc that describes the problem we're trying to solve, and how we intend to solve it would be helpful to me.

[pmuellr]

Could these fields be added to the Connector SOs rather than a separate SO?

We were thinking it would be better to keep these in a separate SO, otherwise the connector SO's will end up getting updated by the system as the tokens are refreshed, etc. Also, if we require schema changes to whatever data we're storing, it's one change vs N connector changes.

[gmmorris]

It's not my place to dictate process, but I think an RFC would be appropriate here. I have a very high level understanding of what we're trying to do, so having a detailed design doc that describes the problem we're trying to solve, and how we intend to solve it would be helpful to me.

Yeah, I tend to agree @legrego.
Changing this kind of thing further down the line is hard, so a more concrete piece of research makes sense here.

We were thinking it would be better to keep these in a separate SO, otherwise the connector SO's will end up getting updated by the system as the tokens are refreshed, etc. Also, if we require schema changes to whatever data we're storing, it's one change vs N connector changes.

Fair points @pmuellr , I was just trying to reduce the overhead caused by maintaining multiple SOs that have these very weak links 😕
Are we expecting multiple Connectors to use the same Auth0 SO? Or will it be a 1-to-1 relationship?

[pmuellr]

Are we expecting multiple Connectors to use the same Auth0 SO? Or will it be a 1-to-1 relationship?

Good question - for the case of connectors that have multiple actions (ie, the case-related ones), I think 1-1 relationship is fine. But you could imagine a story where someone has multiple connectors to the same product, where the OAuth grants could be shared, if that's what the customer wanted to do. Would make it easier to configure - just do it once, share amongst the other connectors (somehow).

My main concern with a separate SO was to keep the mutations on the connectors to a minimum (the SO updated date will change every time we refresh a token), and keep from having to migrate N connector types that might use this, if the OAuth props need to be updated.

[zez3]

But you could imagine a story where someone has multiple connectors to the same product, where the OAuth grants could be shared, if that's what the customer wanted to do

Indeed this is exactly what I had in mind for #94518

[YulNaumenko]

This issue is related to the research #93466

[mikecote]

Closing as we now have a storage mechanism.