Research OAuth flow failure paths

[mikecote]

We should research what user experience will be like for each OAuth authorization code flow step when a failure is detected. How do we plan on supporting or helping with failures at each step? It would be great to cover and check the basic use cases when the entry params is wrong (like Client ID or Secret), when the access/refresh token is expired, or redirect URL is missing in the configured app, when the send email credentials configuration is wrong (pointed to another permissions access), SPA config instead of Web API, etc. It might be good to check all the possible missing/wrong MS App settings.

[elasticmachine]

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

[pmuellr]

[Alerting] OAuth error paths for connectors

Many connectors today support some sort of basic authentication mechanism. However, many 3rd party services also support OAuth, and in some cases are moving to ONLY support OAuth. So, we're looking at how to support OAuth within the alerting framework's connector system. First up: supporting OAuth for usage with Microsoft Exchange, which is dropping traditional SMTP auth and only supporting OAuth. For this research, we'll go more general though. And this research specifically concerns the error paths we anticipate customers could encounter, in hopes of making the errors that are fixable by customers, fixable by customers.

The oauth.com site contains pretty good background material on OAuth, and includes a page on Possible Errors, which includes the following:

• Invalid redirect URL
• Unrecognized client_id
• The user denies the request
• Invalid parameters
• explicit error values
  • invalid_request
  • unauthorized_client
  • unsupported_response_type
  • invalid_scope
  • server_error
  • temporarily_unavailable

errors with login prompts

Any solution requiring browser popup logins will have a common set of errors to deal with:

• the customer provides the authorization URL, and it might be incorrect, or down
• customer's environment does not allow the login UI to be displayed; for instance, popup windows are blocked
• the final redirection to the app from the login UI is incorrect, or down
• everything is correct but auth is denied

Microsoft's generic authorization page includes some diagnostic information when an error occurs; we should do something similar for our redirect page:

dealing with errors occurring over time

• access token expired; there should be a happy path when everything is working to use the refresh token to get a new access token when the current token expires or is invalidated
• refresh token expired
• revocation; not sure what can be revoked, but I imagine both the access token, refresh token, client id/secret.

Presumably any OAuth issues would be flagged like any other alerting error, and show up in details and the alert list. Remediation is discussed below, and would presumably be a relatively normal "edit the connector" flow, probably having to do the initial browser authorization if that's part of the flow.

diagnostics

• debug logging for all error cases
• warn logging for any error conditions not not displayed to user
• any exra diagnostics during test? I don't think we have a way to do this now.
• diagnostics around token expiration (access or refresh)

remediations

We will need to have a flow which will go through the entire authorization flow, for cases where the existing token is invalidated or expired. Presumably this would allow a user to change fields like client_id, and would always require entering the secret field client_secret. Seems likely this is the exact same flow as when the original authorization is created, and so can hopefully be reused.

If we know of permanent errors (not sure how we'd determine that), it's possible we may want to "know" that state in the connector, which would presumably be an action config variable, which would be awkward.

import / export / migration / shareability

I don't think we'll have any special import/export/migration issues for this. OAuth will require a secret for the client secret, and presumably the access and refresh tokens will also be stored as secrets, so should be the same as other secrets in other connectors.

Thinking about future shareability amongst Kibana spaces, I don't think we have any issue with that either.

see also

Some existing places using OAuth in elastic, we can look at for their design / error handling.

https://www.elastic.co/guide/en/workplace-search/7.13/workplace-search-common-source-sync-issues.html

https://www.elastic.co/guide/en/workplace-search/current/workplace-search-onedrive-connector.html

[pmuellr]

Adding as a comment to our generic OAuth issue #79372 and closing as complete