feat(conversation): require auth input for conversation directive

[atierian]

Related PR

• feat(ai): require authorization definition for conversation routes amplify-data#384

Problem

The @conversation directive implicitly uses owner auth (cognito user pool) for associated models and operations because it's the only supported option.

In the future, we may want to extend conversation routes to additional authorization strategies. When that time comes, we'll be forced to make a decision between:

1. implicit owner auth by default, opt into new authorization strategies
   --- or ---
2. breaking change (forcing explicit authorization definition)

Description of changes

We're not going to support additional authorization strategies by GA, but we are making the decision to go with 2. breaking change (forcing explicit authorization definition) already. We're doing this now while we can so that we don't have to make a difficult decision later.

• Adds auth: ConversationAuth! argument to @conversation directive.

The only supported strategy and provider for now are owner and userPools:

input ConversationAuth {
  strategy: ConversationAuthStrategy!
  provider: ConversationAuthProvider!
}
enum ConversationAuthStrategy {
  owner
}
enum ConversationAuthProvider {
  userPools
}

Why not just use @auth?

We could, but that would involve adding a check in the auth transformer that skipped any of it's work if the field also contained a @conversation directive. I'm not ok with doing that.

CDK / CloudFormation Parameters Changed

Issue #, if available

Description of how you validated changes

• E2E test run

Checklist

• PR description included
• yarn test passes
• E2E test run linked
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
• Any CDK or CloudFormation parameter changes are called out explicitly

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[palpatim]

Discussed with @atierian. This seems to be the best of the available options, based on how we have to shuttle auth payloads between clients, AppSync, Lambdas, and tools.

It's a bit unfortunate that we have to have a special-case auth case for this directive, but it's mitigated by the fact that the Gen 2 API acts like a "normal" authorization modifier. That makes the GraphQL directive itself an implementation detail of the happy path; and an escape hatch for customers who use CDK rather than Gen 2.

Approved for both implementation and API bar raiser.