Suppose your team runs a customer portal on AWS. Customers sign in through Cognito and load their invoices through API Gateway. When a customer signs in and gets a 401 instead of an invoice, start by checking where the request stopped. The gateway may have rejected their token, or your app may have denied access.
Both AWS and Forte can check the credentials before a protected request reaches your app. With Cognito and API Gateway, your team connects the identity settings to the API routes. Forte handles sign-in and checks sessions for protected Services within the same project. AWS JWT authorizers · Forte Service authentication
Start with a managed AWS path
For this portal, say your frontend calls an API Gateway HTTP API after the customer signs in. You attach a JWT authorizer to the protected routes so API Gateway can validate the token before passing the request to your backend. Other AWS designs can put that check in a different place. AWS Cognito token verification
Tell the authorizer which user pool to trust and which audience to accept. The audience identifies the app or API the token is meant for. Attach the authorizer to the protected routes and set any scopes they require. A scope is a permission named in the token, so check that the frontend requests the right ones in both staging and production. AWS JWT authorizer configuration
This is a reasonable way to avoid a custom token verifier. It still leaves the team with a set of settings and routes to keep aligned. The app also has to decide whether a signed-in user belongs to the company that owns the invoice.
Locate the failure before changing the app
In the example, a new route rejects a signed-in test user. Start with what the API received. If the request never reached the invoice handler, check the route's authorizer and whether the browser sent the expected token. If the handler ran and denied access, look at the company and invoice rule.
If only one route stopped working after a deploy, start with the settings on that route. If every protected request fails in one environment, look for a setting those routes share. Reproduce the failure with a test account and record the route and status so a teammate can investigate without seeing raw tokens or customer records.
The time your team spends depends on how easily someone can find the system that made the decision. If your AWS setup already has tested infrastructure code and a runbook that points to the right checks, include that automation in the comparison.
Compare the Forte Service path
On Forte, put the protected API on a Service and use Forte's sign-in flow for the project. The gateway checks the session and provides the authenticated user ID to the backend on protected requests. You do not have to create and wire a separate Cognito user pool and API Gateway authorizer for this Forte path. Your invoice handler still checks the user's company before returning a record. Forte Service overview · Forte user authentication
The Service request view gives the team a starting point for status, timing, and available application logs. If a request never ran the app, there may be no handler log to inspect. On requests that reach the handler, include the request ID in your app logs so you can tie its decision to the right call. Forte monitoring guide
Forte supports route exclusions for endpoints that need public access. Keep those exclusions narrow and test the actual deployed route. Forte Websites bypass this Service gateway, so apply the appropriate checks if your site serves protected data itself. Service path exclusions · Forte Website overview
Measure the setup your team will keep
Deploy one invoice route in a test environment and try three kinds of request. Send one while signed out, one as a user from the right company, and one as a user from another company. Then change one setting to cause a safe failure and see how long it takes a second engineer to find the cause. Restore the setting and rerun the checks.
Record the work required to set up each route and to repeat the exercise in the next environment. Compare the same sign-in methods, account requirements, and workload. If AWS meets a requirement that Forte cannot meet, put that in the decision. If both fit, the team can judge what it saves by having sign-in, the session check, and Service diagnostics in the same platform.