验证码前端校验和服务器校验_创建无服务器身份验证API第4部分

验证码前端校验和服务器校验

保护API调用(Securing API calls)

Now that we have a fully functional API that allows you to register and login, the next thing is to put our authentication to good use in the shape of securing API calls.

既然我们有了一个功能齐全的API，可以让您注册和登录，那么下一步就是以确保API调用安全的方式充分利用我们的身份验证。

There’s a couple of ways we can use Cognito as a way to authenticate callers into an API. A very popular way is to use Cognito as an Authorizer for REST APIs. Because this is fairly well documented I will focus on a slightly more complicated use case which is when you want to manually validate a JWT token provided by Cognito. This is a slightly more complicated task but it gives us some granularity on how we handle the errors a bit better.

我们可以使用两种方法将Cognito用作对API进行调用方身份验证的方法。 一种非常流行的方法是将Cognito用作REST API的授权者。 因为这已经被很好地证明了，所以我将集中在一个稍微复杂的用例上，即您要手动验证Cognito提供的JWT令牌时。 这是一个稍微复杂的任务，但它使我们对如何更好地处理错误有了一些粒度。

资源 (Source)

As with all the previous posts, the source for the project I’ve been working on it’s on my personal Github.

与之前的所有帖子一样，我一直在从事的项目的资源都在我的个人Github上。

我们的演示API会做什么？ (What will our demo API do?)

Well we need a demo to illustrate the point, our demo API will return a header. It sounds simple right? A topic I’ve always enjoyed is Microfrontend architectures as it’s a very good way to scale applications to multiple product teams working on separate user spaces so I’ll use a bit of that now.

好吧，我们需要一个演示来说明这一点，我们的演示API将返回标头。 听起来很简单吧？ 我一直很喜欢的一个话题是Microfrontend体系结构，因为它是将应用程序扩展到在不同用户空间上工作的多个产品团队的一种很好的方法，因此我现在将使用其中的一部分。

Imagine as a team you’re responsible for crafting the Header of your application. There’s 2 ( could be more but let’s keep it simple ) states your header will have, one of them is logged in and other is when you have an anonymous request — ie, somebody who’s not logged in.

想象一个团队，您负责设计应用程序的标题。 您的标头将具有2个(可能更多，但让我们保持简单)状态，其中一个状态已登录，另一个状态是当您有匿名请求时(即有人未登录)。

For the case where a user is not logged, we want to see something like this:

对于未登录用户的情况，我们希望看到以下内容：

And for the case of a user that’s logged in

对于已登录的用户

So that’s a fairly simple problem to work with.

因此，这是一个相当简单的问题。

The behaviour we want to achieve is fairly simple:

我们想要实现的行为非常简单：

• Every user with a valid authorised JWT token will be given a logged in header.
  每个拥有有效授权JWT令牌的用户都将获得一个登录标头。
• Every user without specifying a token (or with an incorrect one) will be given the anonymous header.
  每个未指定令牌(或令牌不正确)的用户都将获得匿名标头。

This is where this can be quite handy, because we want to have such a specific custom logic on our flow, doing the authentication ourselves will give us a lot of granularity.

这是非常方便的地方，因为我们希望在流程中具有这样的特定自定义逻辑，因此我们自己进行身份验证将为我们提供很多粒度。

解码JWT令牌 (Decoding a JWT token)

There is a lot to be said on how to decode a JWT token as you need to parse the token from its base64 form, then you need to retrieve your Cognito public keys to then be able to verify your parsed token against your public keys and be able to access the information for the user and their claims.

关于如何解码JWT令牌，您需要说很多话，因为您需要从base64形式解析该令牌，然后需要检索您的Cognito公钥，然后能够针对您的公钥验证已解析的令牌并能够访问有关用户及其要求的信息。

Admittedly that’s a lot, I will not go into the whole process but if you really want to have a look you can check out on the project I created called lambda utils, more exactly on the Security side of it.

诚然很多，我不会介绍整个过程，但是如果您真的想看一眼，可以查看我创建的名为lambda utils的项目，更确切地说是它的安全性方面。

If we use this library, then the process is a bit simpler and the function to check a given token becomes this simple:

如果我们使用此库，则过程会更简单一些，并且检查给定令牌的功能将变得很简单：

All we need is to validate the credentials and make sure they have the right token. If an invalid (or expired) token is provided this will throw an exception and we’ll just get a null back.

我们所需要做的就是验证凭据，并确保它们具有正确的令牌。 如果提供了无效(或过期)的令牌，这将引发异常，我们将得到一个null 。

Once we have this function fully sorted, our lambda can look as simple as this:

一旦我们对该函数进行了完全排序，我们的lambda可以看起来像这样简单：

Important to note how in case of error validating the token or any error we just return an anonymous response. Meaning the users will (almost always) see something even when the validation fails.

重要的是要注意在验证令牌时出错或发生任何错误的情况下，我们仅返回匿名响应。 这意味着即使验证失败，用户也将(几乎总是)看到一些东西。

Because we have the control over the full process, it’s perfect for creating metrics of how many times your API has been called with expired tokens or with fully invalid tokens which can be quite handy for monitoring the availability of your application as a whole.

因为我们可以控制整个过程，所以它非常适合创建度量指标，以使用过期的令牌或完全无效的令牌来调用您的API的次数，这对于监视整个应用程序的可用性非常有用。

结论 (Conclusions)

This was a much shorter post compared to others as we’ve been building on what we’ve done and using some helpers to save a lot of time. If you have the time, dig into the source of validation inside the library quoted as this can bring you some good insights on how it all works.

与其他人相比，这是一篇短得多的文章，因为我们一直在做我们所做的事情，并使用一些帮助程序来节省很多时间。 如果有时间，请在引用的库中挖掘验证源，因为这样做可以为您提供有关所有工作原理的一些很好的见解。

翻译自: https://medium.com/dcms-blog/creating-a-serverless-authentication-api-part-4-52e004a5bf8a

验证码前端校验和服务器校验