Our Apollo Server is running on AWS Lambda using Serverless Framework, and then it's accessed thru AWS API Gateway using Cognito User Pool as an authorizer.&nbsp;<blockquote>More information about Amazon Cognito User Pools can be found in <a target="_blank" rel="noopener noreferrer" href="https://deniapps.com/blog/how-tokens-work-in-amazon-cognito-user-pools">this article</a>.</blockquote><figure class="image"><img src="https://images.unsplash.com/photo-1600695268275-1a6468700bd5?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=MXwxNTQwMTB8MHwxfHJhbmRvbXx8fHx8fHx8&amp;ixlib=rb-1.2.1&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@markusspiske?utm_source=DNX&amp;utm_medium=referral">Markus Spiske</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Our frontend (CMS) is running on top of Create React App with Apollo Client.On the localhost, we use serverless offline, so there is not API Gateway, Cognito User Pool, and Lambda in between the Apollo Client and Apollo Server.We received a lot of complaints from the CMS users that they got the “Failed to Fetch” error a few times almost every day when they were working on the website. &nbsp;When that happened, the CMS cannot communicate to the API server. With console log enable, we saw the information like below:<blockquote>[Network error]: TypeError: Failed to fetch &nbsp;&nbsp;Access to fetch at ‘https://API-URI/graphql’ from origin ‘https://CMS-URL’ has been blocked by CORS policy: "No ‘Access-Control-Allow-Origin’ header is present on the requested resource. If an opaque response serves your needs, set the request's mode to ‘no-cors’ to fetch the resource with CORS disabled.&nbsp;&nbsp;&nbsp;Failed to load resource: https://API-URL/graphql:1 net:ERR_FAILED&nbsp;</blockquote>The hard part to solve this issue is that:<ol><li>There wasn't useful information that could be found in the AWS Cloudwatch</li><li>We could not reproduce it on the local, or on production (with brief test)</li></ol>After spending a lot of time checking the network connection (the CMS can only access via VPN), API Gateway, Lamba, RDS proxy, MySQL database, etc., everything that is different between Localhost and Production, we still could not find the clues.&nbsp;<blockquote>We were pretty sure that the CORS is enabled on Apollo Server. &nbsp;Somehow the server's response does not send the No "Access-Control-Allow-Origin’ header, and the client does not set the request's mode to ‘no-cors’, &nbsp;so the browser throws this error.</blockquote><blockquote>More informatio about CORS error could be found in <a target="_blank" rel="noopener noreferrer" href="https://deniapps.com/blog/false-alarm-of-cors-error">this article</a></blockquote>So, how about eliminating the CORS log first? We need to see the real error log.&nbsp;<blockquote>All debugging starts from the log - Adam C.&nbsp;</blockquote>We took a second look at the API Gateway and found that we should manually add the “Access-Control-Allow-Origin” header to 4xx and 5xx response, otherwise, this header will be missing from the response, and then the real 4xx and 5xx error will be hidden, because the browser will complain CORS errors as shown above.After adding this header with the value “*”, we got the new error report from our CMS users. As expected, we saw the real error message:<blockquote>Failed to load resource: the server responded with a status of 401 ()&nbsp;&nbsp;[Network error]: ServerError: Response not successful: Reveived status code 401</blockquote>After finding the root of failure, the fixing became much more targetable. We quickly figured out that it's related to the Cognito user pool, which we use as an authorizer. The AccessToken and IDToken are set with a short expiration time of one hour, so if the user is on the website for more than one hour, &nbsp;he/she will use pass an expired token for API call, therefore, the 401 unauthorized error will be received. Also, after refreshing the page, everything is back to normal, that's because the lifetime of refreshToken is one day, and Amplify will auto-refresh the AccessToken and IDToken as long as the refreshToken is not expired.&nbsp;So the solution is clear that we just need to refresh the AccessToken/IDToken when they are expired, but we need to do this in the background without refreshing the page, otherwise, the user's unsaved work will get lost. &nbsp;We use Amplify React UI Component to handle user login. When the login is successful or the user is already logged in, the ID token is passed to Apollo authLink as below:<pre><code class="language-javascript" id="80kA0Le8f">Auth.currentAuthenticatedUser().then(async (user) =&gt; {
 const token = user.signInUserSession.idToken.jwtToken;
 const authLink = new ApolloLink((operation, forward) =&gt; {
 // Use the setContext method to set the HTTP headers.
 operation.setContext({
 headers: {
 authorization: token ? `Bearer ${token}` : ""
 }
 });

 // Call the next link in the middleware chain.
 return forward(operation);
 });
});</code></pre>The logic above is implemented in the App.js, which is the parent component of all, and it's only run once at the componentDidMount lifecycle, so without refreshing the page, the token is never changed. But as we learned above, when the token is expired, the 401 unauthorized error is received. The Apollo Client allows us to check for a certain failure condition or error code, and retry the request if rectifying the error is possible. Below is what we came up using the ErrorLink: (If you are not familiar with Apollo Link, check it out <a target="_blank" rel="noopener noreferrer" href="https://www.apollographql.com/docs/react/api/link/introduction/">here</a>)<pre><code class="language-javascript" id="hAPivEyJR">const handlErrorLink = onError(
 ({ graphQLErrors, networkError, operation, forward }) =&gt; {
 if (graphQLErrors)
 graphQLErrors.forEach(({ message, locations, path }) =&gt;
 console.log(
 `[GraphQL error]: Message: ${message}, Location: ${locations}, Path: ${path}`
 )
 );
 if (networkError) {
 if (String(networkError).match(/Received status code 401/i)) {
 return fromPromise(
 Auth.currentAuthenticatedUser()
 .then(async (user) =&gt; {
 return user.signInUserSession.idToken.jwtToken;
 })
 .catch((error) =&gt; {
 console.log("refresh token failed: ", error);
 // Handle token refresh errors e.g clear stored tokens, redirect to login, ...
 return;
 })
 )
 .filter((value) =&gt; {
 return Boolean(value);
 })
 .flatMap((token) =&gt; {
 const oldHeaders = operation.getContext().headers;
 // modify the operation context with a new token
 operation.setContext({
 headers: {
 ...oldHeaders,
 authorization: `Bearer ${token}`,
 },
 });
 return forward(operation);
 });
 }

 console.log(`[Network error]: ${networkError}`);
 }
 }
);</code></pre>Note the in our case, the 401 unauthorized is captured in networkError, and the error string contains “<code>Received status code 401”</code> which we used to filter, and <code>Auth.currentAuthenticatedUse,</code> the function provided by ‘Amplify’ is asynchronous, so we have to use <code>fromPromise,</code> the function provided by ‘apollo-link’ to token from a Promise object, and then replace the old header in operation context, finally forward the operation to retry.After this, we had the annoying ‘failed to fetch’ error fixed. :-)&nbsp;

In this article, we learned how to fix the 'failed to fetch' error from API-Gateway in our AWS Lambda Serverless Framework. The root cause is ended up to be the expired AWS Cognito Access/ID tokens. We were able to fix this by utilizing the Apollo Error Link to replace the old token with the refreshed one, and then retry the request.

Finally We Fixed "Failed to Fetch" Error

AWS provides us Amazon Cognito User Pools, which could be used as authorizer to control access to our application. Per <a target="_blank" rel="noopener noreferrer" href="https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html">Amazon Doc</a>: &nbsp;Amazon Cognito user pools implement ID, access, and refresh tokens as defined by the OpenID Connect (OIDC) open standard:<ol><li>The <a target="_blank" rel="noopener noreferrer" href="http://openid.net/specs/openid-connect-core-1_0.html#IDToken">ID token</a> contains claims about the identity of the authenticated user such as <code>name</code>, <code>email</code>, and <code>phone_number</code>.</li><li>The <a target="_blank" rel="noopener noreferrer" href="https://tools.ietf.org/html/rfc6749#section-1.4">access token</a> contains scopes and groups and is used to grant access to authorized resources.</li><li>The <a target="_blank" rel="noopener noreferrer" href="https://tools.ietf.org/html/rfc6749#section-1.5">refresh token</a> contains the information necessary to obtain a new ID or access token.</li></ol>When we sign in the user pool using Amplify, we will obtain all those three tokens.&nbsp; &nbsp;<figure class="image"><img src="https://images.unsplash.com/photo-1475701240414-7842311479e7?ixlib=rb-1.2.1&amp;q=80&amp;fm=jpg&amp;crop=entropy&amp;cs=tinysrgb&amp;w=1080&amp;fit=max&amp;ixid=eyJhcHBfaWQiOjE1NDAxMH0"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@genessapana?utm_source=DNX&amp;utm_medium=referral">Genessa Panainte</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h3>Which Token to Call API?</h3>Normally, the ID token is for Authentication, and the access token is for Authorization. When calling the API method, we typically set the token to the request's Authorization header. So, it sounds like we should use the access token, doesn't it? Based on the doc, we could use either the ID token or the access token. However, &nbsp;as we tested, we should use the ID token. That's because:<ol><li>The ID token is used to authenticate users to our resource servers or server applications (ex: API)</li><li>The purpose of the access token is to authorize API operations in the context of the user in the user pool. For example, you can use the access token to grant your user access to add, change, or delete user attributes.</li></ol><h3>What's the Refresh Token?</h3>Usually, we set the access token/the ID token expiration to be much shorter than the refresh token expiration. And then when the access token/the ID token expires, we can use an unexpired refresh token to get a new access token/ID token without asking users to re-login. The reason behind this is that the access token/the ID token is used to API method, in case they are stolen, the short expiry time could help minimize the damage.&nbsp;<h3>Will the Refresh Token Expires?</h3>Yes, with Amazon Cognito User Pool, we can set the app's refresh token expiration to any value between 60 minutes and 10 years.&nbsp;<h3>How to Check if the Refresh Token Expired or Not?</h3>Different to the access token/the ID token, which is the JWT token where we can get the expiration date, we cannot tell if the Refresh Token Expired or not from the token. But we can tell it from the auth_time of the refresh token/the ID token. For example, we set the refresh token expiration to 1 day, then we can use the following equation to get the refresh token expiration DateTime:<pre><code class="language-javascript">const authTime = user.signInUserSession.accessToken.payload["auth_time"];
const refreshTokenExpirationTime = 
	new Date(authTime * 1000 + 24 * 60 * 60 * 1000)</code></pre><h3>Possible Issues When Refresh Token is Expiring</h3>We set the access token expiration to be 60 mins, and the refresh token expiration to be 1 day. We use the Amplify library, which auto-refreshes the token when the access token expires, we basically get the 1-day session duration. Note that when the refresh token expires, the user has to re-login to get the new access token, ID token, and refresh token. So if the user is working on something when both the ID token and the refresh token are expired, then the unsaved work will be lost.To understand how this works, let us use an example:<ul><li>The user logged in today at 9:00 am, he got an&nbsp;accessToken (valid until 10:am) and a refresh token (valid until 9 am tomorrow)</li><li>He comes back at 10:30 am, and his access token expires, but he is still logged in because his session is refreshed by the refresh token and he gets the new access token (valid until 11:30 am) and his refreshToken is still valid until 9 am tomorrow.</li><li>He comes back tomorrow at 8:30 am, he is still logged in, again thanks to the refresh token, and he gets a new access token valid until 9:30 am, then there is an issue because at 9:31 am, he has to re-login since&nbsp;his refresh token will be&nbsp;expired at that time. So his unsaved work will be lost at 9:31 am.</li></ul><h3>How to Handle When Refresh Token is Expiring</h3>If your application has an auto-save feature, like Gmail App, then how the refresh token works as we discussed above should be fine. Otherwise, we may look into some solution to manually log out the user at the right time to avoid losing unsaved work.<h4>Solution One</h4>Log out the user when the refresh token is about to expire in 60 mins, and we can check this when the page loads and when the user is active right after idle. In the other words, if the refresh token is not expired in 1 hour, then the user could get one more refresh, which could mitigate the session losing.&nbsp;<h4>Solution Two</h4>Implement the strict mode, for example, log out the user after the idle time is more than &nbsp;15 mins, which could be a popup to allow the user to extend the session (by setting a longer refresh token expiration.) Also, log out the user when we detect the refresh token expiration time is in a day at the initial page load. But this solution will sacrifice the benefit of the refresh token.We know both solutions are not great. So if you have any ideas, please leave your comments.

AWS provides us Amazon Cognito User Pools, which could be used as authorizer to control access to our application. The article will explain all three tokens implemented by Cognito User Pools, and discuss some common questions of how to use those tokens.

All Posts In Cognito