Amplify-cli: Unauthorized read / update on GraphQL from client

[houmark]

* Which Category is your question related to? *

I need to read (but not list) an a single item (based on query on a get query) using AppSync/GraphQL and later update that same item in the browser (react). The user will not and cannot be logged in (a fake user could be an option, but seems very hacky). I've seen a lot of random guides and writeups on this, but I just can't seem to grab what's the best practice right now. I understand new features in relation to this is on the way, but I need something working this week.

When creating the API, you get the option to allow "unauthorized" access, but what does that cover, and how does that work?

I'm hoping for someone to do a writeup on what services to change, which policies exactly to add and where to add them (in Amplify configuration files or in the AWS web UI), and then how to modify my schema.graphql for this to work.

* What AWS Services are you utilizing? *

Most Amplify supported services, including AppSync / GraphQL, Cognito, storage, functions etc.

[attilah]

@houmark Unauthorized access means, what your API endpoint will still require http requests with SIGv4 signatures, but you don't need to get it for an authenticated user.

@dabit3 has a sample application around this topic: https://github.com/dabit3/appsync-auth-and-unauth.

I think this answers your question so I'm closing this issue, if you have further questions, feel free to re-open it a later time.

[houmark]

I saw that sample app and to be honest, it seems somewhat complex. Does this mean that every time I add a new Model in my schema I will have to actively add access in the inline policy for every type of query and mutation? Even if those are only used by Cognito authorized users?

I've seen writings about @aws_iam inline in the schema, but that's unreleased, though supposed to be very close to release. How does that change all of this? Will work similarly and require the same manual configuration or will it be simpler from a day to day active development perspective? I've considered an alternative standard REST endpoint with an API key access and write directly to dynamodb or through a server side GraphQL client for this one model I need to read and update anonymously as a temporary solution until a more "out of the box" Amplify solution is released.

A simple question; Will authenticated Coginito users have the same access control as now without adding any inline policy changes when adding new models? I know I should be testing this out, but I've spent a lot of time in this first Amplify project experimenting due to lack of documentation, and several times without any success, so I'm looking to clarify some things here before I jump in and try this.

[houmark]

My hesitation towards the solution from @dabit3 (no bad will here, just thinking there's something new coming up, he is working on making a sample for that could replace the old sample) comes from a question by him 9 days ago in #1710.

The sample @attilah linked is 5 months old and if we can agree it's not the most clean and minimalist solution, then maybe there's something better on the way? If that's the case, then I'd prefer a simpler (the REST endpoint) workaround which does not mess around with my entire authorization configuration using @auth, Coginito groups etc.

[dabit3]

@houmark we also added support for both authorized and unauthorized roles in AppSync as outlined here -> https://aws.amazon.com/blogs/mobile/using-multiple-authorization-types-with-aws-appsync-graphql-apis/

Not yet implemented into the Amplify CLI yet but is coming, but is completely supported by the Amplify client and AppSync client

[houmark]

@dabit3 Thanks for that. I had hit that post once but gotten away from it. Couldn't find it in a Google Search for some reason. Long post, but looks promising and a more clean solution.

I'll read it and may come back here for clarification. Thanks again!

P.S. Since your repository with the sample seems to get some attention, you may want to link the blog post the new option for doing this in the top of the README?

[dabit3]

@houmark Great idea, I've updated my example repo with a link to the post.

[stefangomez]

@houmark - check out my comment here: https://github.com/aws-amplify/amplify-cli/issues/1576#issuecomment-507467641

[dabit3]

Hey @stefangomez thanks a lot for the detailed comment, it will definitely be helpful for others looking for different ways to implement this.

In the meantime, we're continuing to work on improving the implementation of this via the CLI as well as the AppSync service because we know it's a very common use case and it is one of our priorities.

[dabit3]

Coming back to this, the Amplify CLI enables this really easily now.

It is implemented in both Amplify and AppSync. If you are using the Amplify CLI, you can choose multiple authorization modes by running amplify update api. The following schema would allow both authenticated and unauthenticated access:

type Todo @model 
  @auth(
    rules: [
      { allow: owner }, # owner can update, delete, and read
      { allow: private, operations: [read] }, # signed in users who are not the owner can read
      { allow: public, operations: [read] } # unauthenticated users can read
    ]
  )
 {
  id: ID!
  name: String
}

When calling the API from the Amplify Client, you can define the authorization mode if it is not the default using one of the following authorization modes:

__API_KEY__
__AWS_IAM__
__OPENID_CONNECT__
__AMAZON_COGNITO_USER_POOLS__

const createdTodo = await API.graphql({
  query: queries.createTodo,
  variables: { input: todoDetails },
  authMode: 'AMAZON_COGNITO_USER_POOLS'
});
copy