Amplify-cli: create custom authorizer within CLI - manually created authorizer will be overwritten

[blomm]

Is your feature request related to a problem? Please describe.

Yes, I am unable to configure a custom authorizer (cognito) with the CLI, and also unable to use the CLI to set my api gateway to use COGNITO_USER_POOLS

Describe the solution you'd like
something similar to the suggestion in this closed (inactivity) issue:
https://github.com/aws-amplify/amplify-js/issues/1702

Authorizer:
Name: CustomerCognitoAuthorizer
Type: COGNITO_USER_POOLS
ProviderARNs:
- !Ref CustomerCognitoPoolARN
IdentitySource: "method.request.header.Authorization"

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
I've tried to manually created the "custom authorizer", but every time I amplify push it will get overwritten/removed.

amplify-API docs mention:

"Cognito User Pools Authorization
You can use the JWT token provided by the Authentication API to authenticate against API Gateway directly when using a custom authorizer."
.
..but I can't find a way to create this custom authorizer in the CLI.
Am I just going about this the wrong way??

[blomm]

thanks @Ashish5591, surely it must be possible to use COGNITO_USER_POOLS with the cli? do you know what I'm doing wrong?

[blomm]

any thoughts @attilah ?

[kaustavghosh06]

@blomm At the moment, the CLI doesn't support Cognito custom authorizers out of the box. (although you can modify the APIGW Cloudformation tempalte and manage it yourself).
Having said that, the CLI does support IAM authorization which works well with Cognito Idenity and user pools.

[blomm]

thanks very much @kaustavghosh06 , can you steer me towards some documentation on implementing this?

[blomm]

@kaustavghosh06
I've investigated rolling my own cloudformation template for Custom Authorizer, and it's way too complicated. I'm just going to end up breaking my existing amplify-generated template.
The other option of using IAM is not much easier:
I'm roughly following this:
fine-grained authorization using Amazon Cognito User Pools groups
The user pool and identity pool get created for me with auth in Amplify.

Correct me if I'm wrong but I need to then manually do the following:

1. Create Policy that says what/how a user can query dynamo tables

"Action": [
                "dynamodb:GetItem",
                "dynamodb:PutItem",
                "dynamodb:Query"
            ],
            "Resource": [
                "arn:aws:dynamodb:eu-west-1:<account-id>:table/<my-table>"
            ]

1. Create Role, add above policy to this role.
2. Create Cognito Group (myGroup), attach above Role to Group
3. Attach myGroup to desired cognito users

I've done all the above, I log in with a cognito user who belongs to _myGroup_ and now I'm trying to pass my auth token from the frontend to api-gateway:

• on the frontend I call Auth.currentSession() which returns currentUser

• I add to my Headers a _Authorization_ property and set to currentUser.getIdToken().getJwtToken()

When I decode my jwt token, I can see that my user belongs to the group _myGroup_
But my attempts to call my api-gateway endpoint result in 403's.

So, I dig a bit more and I find out that:

when you change to use AWS_IAM as the authorizer for your API Gateway method the request must now contain specific amazon headers and not just Authorization header.

Is there some documentation on how amplify creates and implements the necessary signed header for us?

[blomm]

Hi @kaustavghosh06,
Do you know if anyone on your side is currently working on supporting custom authorizers (with cognito user pools)?
I'm probably going to need to abandon Amplify and switch to using Serverless (where custom authorizers works very well) until this has been implemented.

[steffengr]

We are currently stuck with the same issue. We currently configure the authorizer and the gateway by hand but we have to redo it every time we add a new path as that overwrite the configuration. I'm now investigating editing the cloudformation templates manually. Is there any example for how to do that? Doing it with the API would preferred though to avoid conflicts with changes done by amplify.

[blomm]

Hi @steffengr,
For documentation, I found this link below, and started to have have a crack at rolling my own cloud-formation template, but I've found the amplify cloud-formation stuff to be like a house of cards (the amount of times I've started my backend over again from scratch), so I'm frightened to touch it.
If you figure it out, let me know please, and also as I said, Serverless implements it really easily, a few lines in the yml file, and you're good. So it's possible to just use Amplify for storage or auth and leave the api-gateway / lambda scaffolding work with Serverless.
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-authorizer.html

[kylekirkby]

Thanks for the report @blomm & @steffengr ! This looks quite involved as it stands. Is there any update on this @UnleashedMind & team? Is this in the roadmap at all ?

Cheers,

Kyle

[blomm]

Thanks @kylekirkby , Serverless support this custom authorizer directly from the yml file, so it shouldn't be too big a task, just a matter of setting up the code to generate the cloudformation, and add this as a step in the cli

[kylekirkby]

@attilah @kaustavghosh06 any idea if this is doable? Would be awesome to have Lambda Authorizers added so we can provide a custom lambda function for authenticating users. I've got a SaaS product which creates multiple API keys for users projects and currently I'm doing the lookup of the API key via the lambda function that does the business logic. I'd love to be able to separate this logic out for checking if their API key is valid so this can be re-used easily across functions.

[nguyenan]

Same issue here. Appreciate sharing any ETA on this.

[kylekirkby]

@attilah @kaustavghosh06 @powerful23 @dabit3, can you use any of your special powers to get this issue expedited?

[dabit3]

Hey @kylekirkby, checking on this now.