amplify-js: Graphql's custom-auth lambda function is not invoked.

Hey @imdhanush sorry for the delay. Just to want to make sure I understand your use case.

Is there a reason why you’re using a Lambda to verify Cognito tokens instead of utilizing the private or group auth rules instead for both models?

If you need that much control over the authorization model, you could potentially manage all of the logic from within the lambda and set both models to custom auth.

For example, I changed my schema to this

type Module @model @auth(rules: [{ allow: custom }]) {
  id: ID!
  name: String
}

type Permission @model @auth(rules: [{ allow: custom }]) {
  id: ID!
  name: String
  module: Module @hasOne
}

Using only the custom lambda to authorize the calls, I can verify that a cognito user is making the call, check what groups they belong to, and restrict what fields, queries, mutations, etc each user can access accordingly using the deniedFields part of the response

Lambda example:

const { CognitoJwtVerifier } = require("aws-jwt-verify");

exports.handler = async (event) => {
  console.log(`event >`, JSON.stringify(event, null, 2));

  const {
    authorizationToken,
    requestContext: { apiId, accountId },
  } = event;

  let response = {
    isAuthorized: false,
    resolverContext: {
      userid: "test user",
      info: "contextual information A",
      more_info: "contextual information B",
    },
    deniedFields: [
      `Mutation.createPermission`,
      `Mutation.updatePermission`,
      `Mutation.deletePermission`,
    ],
    ttlOverride: 0,
  };

  try {
    const verifier = CognitoJwtVerifier.create({
      userPoolId: "us-east-1_UrraAvHrw",
      tokenUse: "access",
      clientId: "7gb622j3ir3oatedu8fodci6ev",
    });

    const jwt = authorizationToken.replace(/^Bearer\s/, "");

    const payload = await verifier.verify(jwt);
    console.log("Token is valid. Payload: ", payload);

    if (
      payload["cognito:groups"] &&
      payload["cognito:groups"].includes("enterprise-admins")
    ) {
      response.deniedFields = []; // allow enterprise-admins group to perform any action
    }

    response.isAuthorized = true;
  } catch (error) {
    console.log("Token not valid");
  }

  console.log(`response >`, JSON.stringify(response, null, 2));
  return response;
};

listPermissions ( valid Cognito access token )

createPermission ( user does not belong to any group)

createPermission (user belongs to enterprise-admins group)

Let me know if this helps

@arundna Just a heads up: we had “Bearer” in front of our OIDC tokens for lambda auth for the last 2 months as a workaround but it randomly stopped working today and started to return the error “Not authorized to perform x on type Query”. Changing the prefix to anything else caused it to start working again. Is “Bearer” a reserved word for something else now in AppSync or Amplify? I don’t see this documented anywhere but Bearer no longer works for us.

@thegoliathgeek Apologies for the delayed response on this one. @chrisbonifacio worked with our AppSync team and we’ve made changes to our AppSync documentation to clarify the scenario and also added the workaround section - Circumventing SigV4 and OIDC token authorization limitations

https://docs.aws.amazon.com/appsync/latest/devguide/security-authz.html#aws-lambda-authorization

I’ll go ahead and close this out, but feel free to open a new issue if you have further questions.

Hey @chrisbonifacio , Yes I’ll move all models to custom auth. Thank you 😃.

Hey @chrisbonifacio Thank you for this. But can this be fixed? So that we don’t have to use Bearer in the auth header for custom-auth.

type Module @model @auth(rules: [{ allow: custom }]) {
  id: ID!
  name: String
}

type Permission
  @model
  @auth(
    rules: [
      { allow: groups, groups: ["enterprise-admins"] }
      { allow: private, operations: [read] }
    ]
  ) {
  id: ID!
  name: String
  module: Module @hasOne
  create: Boolean
  read: Boolean
  update: Boolean
  delete: Boolean
}

For the above schema i’ll make a nested query like this

query{
 listPermissions{
  items{
    id
    name
    module{
      id
      name
    }
  }
}
}

As both models have different authorization rules. Permission model requires Authorization: {jwt} Module model (custom-auth) requires Authorization: Bearer {jwt}

{
  "data": {
    "listPermissions": {
      "items": [
        {
          "id": "d7cb9f3b-eb62-4fc6-a0a7-80426142c4cd",
          "name": "editors_permission",
          "module": null
        }
      ]
    }
  },
  "errors": [
    {
      "path": [
        "listPermissions",
        "items",
        0,
        "module"
      ],
      "data": null,
      "errorType": "Unauthorized",
      "errorInfo": null,
      "locations": [
        {
          "line": 6,
          "column": 5,
          "sourceName": null
        }
      ],
      "message": "Not Authorized to access module on type Module"
    }
  ]
}

Now only Permission module is accessible. If we pass auth header with Bearer {jwt}

The whole query fails.

So, after digging into this further. It seems you were right - the requests without Bearer in the auth header are being auto-rejected by AppSync. Had to turn on my AppSync logs too see that (which I don’t recommend, as it can have unexpected increases on your bill).

So, I’m not quite sure why a jwt without Bearer gets auto-rejected when a regular string like "test12345" doesn’t - still trying to figure that out.

But, I also found that not including an auth token in your API.graphql call with an authMode of AWS_LAMBDA will result in an error.

So, Amplify wouldn’t have automatically made the request with its usual auth header anyway. So, I don’t think this is an issue or bug, at least not with the JS library.

You’ll have to adjust your lambda to remove the Bearer part of the auth header before verifying it but once you do that, just include it in your call and the lambda should work like you’d expect.

My lambda logic

const { CognitoJwtVerifier } = require("aws-jwt-verify");

exports.handler = async (event) => {
  console.log(`event >`, JSON.stringify(event, null, 2));
  const {
    authorizationToken,
    requestContext: { apiId, accountId },
  } = event;

  let isAuthorized = false;

  const verifier = CognitoJwtVerifier.create({
    userPoolId: "us-east-1_UrraAvHrw",
    tokenUse: "access",
    clientId: "7gb622j3ir3oatedu8fodci6ev",
  });

  // have to include "Bearer" in the auth header for the lambda to be invoked, but we'll remove it here to verify the token
  const jwt = authorizationToken.replace(/^Bearer\s/, ""); 

  try {
    const payload = await verifier.verify(jwt);
    console.log("Token is valid. Payload: ", payload);
    isAuthorized = true;
  } catch (error) {
    console.log("Token not valid");
  }

  const response = {
    isAuthorized,
    resolverContext: {
      userid: "test user",
      info: "contextual information A",
      more_info: "contextual information B",
    },
    deniedFields: [
      `arn:aws:appsync:${process.env.AWS_REGION}:${accountId}:apis/${apiId}/types/Event/fields/comments`,
      `Mutation.createEvent`,
    ],
    ttlOverride: 300,
  };

  console.log(`response >`, JSON.stringify(response, null, 2));
  return response;
};

Client-side API GraphQL query

const res = await API.graphql({
  query: listTodos,
  authMode: "AWS_LAMBDA",
  authToken: `Bearer ${(await Auth.currentSession())
    .getAccessToken()
    .getJwtToken()}`,
});

Result:

🙌