Summary
In modern systems built on AWS, separating authentication and authorization is a common architectural pattern. AWS Cognito usually handles authentication, while access control is implemented via backend ACL (Access Control List).
This article shares practical testing experience, focusing on how to test role-based access in applications that use AWS Cognito combined with ACL, to ensure correctness and system security.
1. Overview of Authentication and Authorization Architecture
The system includes the following main components:
AWS Cognito: Handles user authentication (sign-up, login), and manages tokens (access_token, id_token).
Frontend: Uses Cognito for login, stores the token in browser memory, and attaches it to requests.
Backend (API Gateway + Lambda): Reads the token to identify the user, then applies ACL to check whether the user is allowed to access a specific API or resource.
Authorization does not happen in Cognito. Cognito provides identity information (such as role, groups), and the backend makes the final decision about access based on ACL.
2. Goals of Access Control Testing
Access control testing aims to confirm that:
- Users can only access functions and data they are allowed to.
- The system handles unauthorized access properly, with correct and secure responses.
- Potential mistakes, such as privilege escalation, are detected early.
3. Testing Strategy
3.1 Create Representative User Accounts
To cover all authorization paths, the test team prepares user accounts for common roles in the system:
| Role | Testing Purpose |
|---|---|
| Admin | Full access |
| Editor | Create/edit data |
| Viewer | View only |
| Guest | Not logged in |
3.2 Testing via Application Interface
Use the actual UI and Cognito login flow. Do not manually insert tokens.
3.3 Combine UI and API Testing
- Use the app interface to log in and perform actions.
- Open browser DevTools (Network tab) to check requests:
- Token is attached correctly?
- Token is attached correctly?
- Check if the UI shows or hides features based on roles.
3.4 Test Unauthorized Scenarios
- Access restricted pages using the wrong roles.
- Perform actions not allowed for a role (e.g. delete, update), and confirm the system blocks them correctly.
4. Common Errors Observed
| Type of Error | Description |
|---|---|
| Wrong ACL mapping | Token has the correct role, but backend checks fail |
| UI shows actions beyond permission | UI still allows actions not permitted |
| Backend skips permission check | API performs actions without verifying the token |
| Expired or fake tokens accepted | Tokens not properly validated |
5. Suggested Access Control Testing Process
- Identify all user roles and their permissions.
- Log in with each role, one by one.
- Check UI behavior:
- Which features are shown or hidden?
- Is access restricted or redirected?
- Observe API requests:
- Is the correct token used?
- Does the system respond according to the user’s role?
- Try unauthorized actions and verify system blocks them.
6. Conclusion
Access control is critical for system security and user experience. Testing access control ensures the application behaves correctly for each user role, and prevents unauthorized access.
For systems using Cognito and ACL:
- Cognito identifies the user, not their permissions.
- Each role must be thoroughly tested, including valid and invalid scenarios.
- Careful testing helps prevent security issues before they appear in production.