Fix/custom auth 500

[petrkalos]

Feature or Bugfix

• Bugfix

Detail

Currently when access is denied we raise exceptions which have 2 side effects

• APIGW returns 500 Internal Server Error to the user which is confusing
• Deny cache is not populated hence increasing the traffic that IdP is receiving

In this change we return an explicit Deny policy for all known scenarios and raise an exception otherwise.
The known scenarios include

• We receive 401 from Cognito which means invalid access token (unauthorized access)
• We receive 403 from Cognito which means throttling
• We fail to validate the jwt token returned by Cognito

Relates

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

• Does this PR introduce or modify any input fields or queries - this includes
  fetching data from storage outside the application (e.g. a database, an S3 bucket)?
  • Is the input sanitized?
  • What precautions are you taking before deserializing the data you consume?
  • Is injection prevented by parametrizing queries?
  • Have you ensured no eval or similar functions are used?
• Does this PR introduce any functionality or component that requires authorization?
  • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
  • Are you logging failed auth attempts?
• Are you using or adding any cryptographic features?
  • Do you use a standard proven implementations?
  • Are the used keys controlled by the customer? Where are they stored?
• Are you introducing any new policies/roles/users?
  • Have you used the least-privilege principle? How?

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

[noah-paige]

do we need to add USER_ID: None to this dict too? - i.e. {'sub': None, EMAIL_CLAIM: None, USER_ID: None}

Otherwise do we run the risk of getting KeyError when updating context as 'user_id': verified_claims[USER_ID_CLAIM],?

[petrkalos]

I could yes but currently it's working (I tested it) because both email and user_id env variables are equal to email

[dlpzx]

Looks good. As commented offline there other exceptions that could go wrong but those are things on Cognito that we would want to raise