Amplify-cli: Allow @auth read access to all, and write access to some groups

[plaa]

The GraphQL @auth annotation can be used to provide authorization rules to the API. If the annotation is missing, access is granted to all authenticated users.

How can I provide read access to all authenticated users, and mutation access to those in particular groups? Effectively, I'm looking for some kind of allow: all option:

@auth(rules: [
    { allow: all, mutations: null },
    { allow: groups, groups: ["Admin"] }
])

A workaround would be to create some kind of 'Everyone' group and create a Lambda function to make sure all new users are added to that group, but it seems unnecessarily cumbersome.

Also relevant to this question (and which is not addressed in the docs!) is how are the rules evaluated? Does evaluation stop on the first matching rule and apply that, or are the granted permissions a union of all rules that match?

[jkeys-ecg-nmsu]

@plaa you can use a Cognito signup trigger to ensure that your admin-add-to-group code is executed only once per user.

[plaa]

I know I can subscribe all users to an "Everybody" group using a trigger, it just seems like unnecessarily cumbersome steps to achieve very basic functionality.

The workaround would be:

@auth(rules: [
    { allow: groups, groups: ["Everyone"], mutations: null },
    { allow: groups, groups: ["Admin"] }
])

but it would be much simpler to use be able to use some catch-all in the rules (e.g. allow: all).

[mikeparisstuff]

@plaa Subscribing everyone to the "Everyone" group will do the trick. You can also specify that the "Admin" rule should only apply to create, update, and delete operations.

@auth(rules: [
    { allow: groups, groups: ["Admin"], operations: [create, update, delete]}
])

Having an allow: authenticated will become necessary when and/or rules or strict mode are introduced to @auth. Here is another ticket discussing a similar idea. #52

[plaa]

Can this then be considered a feature request? allow: all, allow: authenticated or similar would be useful even without and/or rules. (Not sure how #52 is relevant, did you mean something else?)

Also please add to the docs how the rules are evaluated. My guess is that a user gains a union of all permissions from any rules that match the user, but not 100% sure.

[mikeparisstuff]

@plaa Yes this will be useful once we have and/or rules and can be viewed as a feature request.

Currently the rules are joined with an OR. The goal is to support and/or in complex configurations.

[plaa]

This would be really useful currently as well. The workaround of having all users in an 'Everyone' group can produce very strange bugs if the condition ever fails. Especially so because the List* queries produce an empty array instead of an error even though you don't have any rights to the API.

I just spent an hour trying to figure out why documents I've just created aren't showing up, even though they're in the DB. My admin user (created by hand through the Cognito console) wasn't in the 'Everyone' group. Such bugs would be nonexistent with this feature.

[Mellgood]

I assume that there is no default group for cognito users... am I right? Is there any other way to reference to all groups or maybe to all users like a "*"?

[gitzhouxinyu1]

Any updates?

[kaustavghosh06]

Hey guys, we recently recently released multi-auth support - where you can use IAM to control access to auth/guest users. This would work for the above-mentioned use-case. Please take a look at the docs for info - https://aws-amplify.github.io/docs/cli-toolchain/graphql#private-authorization

[pnutmath]

Just valid url for private authorization doc is here https://docs.amplify.aws/cli/graphql-transformer/directives#private-authorization