有没有办法保护 React JS 中的 API 密钥，即使它在客户端? [英] Is there anyway to secure API keys in React JS, even though it's on the client side?

问题描述

在 React javascript 文件上使用 API 密钥时，是否有保护它的方法?例如;

Is there anyway to secure an API key when using it on a React javascript file ? For example;

emailjs.init("API_KEY");

推荐答案

您可能想查看 Google Firebase 如何进行纯客户端身份验证:https://firebase.google.com/products/auth/

You may want to check how Google Firebase does pure client-side authentication: https://firebase.google.com/products/auth/

使用 API 密钥、OAuth 等进行身份验证的一般介绍(来源:关于构建网络应用程序的 codecademy 课程)可能有助于理解 API 密钥的用途以及为什么不需要保护它们.原因是还有其他方法可以处理机密信息，如本文所述.

Edited: This general introduction to Authentication using API-keys, OAuth etc (source: codecademy course on bulding web-apps) may help understand what API keys are meant for and why it should't be necessary to secure them. The reason is that there are other ways to deal with secret information, as described in this article.

身份验证

简介

身份验证是应用程序用来确定和确认用户身份的过程.它确保向用户显示正确的内容.更重要的是，它可以确保不正确的内容受到保护，未经授权的用户无法访问.

Authentication is the process used by applications to determine and confirm identities of users. It ensures that the correct content is shown to users. More importantly, it ensures that incorrect content is secured and unavailable to unauthorized users.

在本文中，我们将讨论这些交互的一些常见设计模式.您需要对 HTTP 请求有一些基本的了解，因为这些方法都使用 HTTP 请求来交换信息.

In this article, we’ll discuss a few of the common design patterns for these interactions. You’ll need to have some basic understanding of HTTP requests, since these methods all use HTTP requests to exchange information.

密码验证

最常见的身份验证实现要求用户输入其用户名或电子邮件地址和密码.然后，应用程序的服务器检查提供的凭据以确定用户是否存在以及提供的密码是否正确.如果凭据正确，则用户已登录并能够以该用户的身份使用该应用程序.

The most common implementation of authentication requires a user to input their username or email and a password. The application's server then checks the supplied credentials to determine if the user exists and if the supplied password is correct. If the credentials are correct, the user is logged in and able to use the application as thatthe user.

通常，在成功登录后，应用程序将使用身份验证令牌(或身份验证令牌)进行响应，供客户端用于其他 HTTP 请求.此令牌随后会存储在用户的计算机上，从而避免用户持续登录.

Typically, upon a successful login, the application will respond with an authentication token (or auth token) for the client to use for additional HTTP requests. This token is then stored on the user's computer, preventing the need for users to continuously log in.

此令牌通常会在一段时间后过期，以确保正确的用户也会随着时间的推移使用该应用程序.

This token generally expires after a certain amount of time, ensuring the correct user is using the application over time as well.

API 密钥

虽然通常将身份验证视为人类用户与应用程序之间的交互，但有时用户是另一个应用程序.

While it is common to think of authentication as the interaction between a human user and an application, sometimes the user is another application.

许多应用程序以 API(应用程序接口)的形式向其信息公开接口.例如，Spotify API 为其几乎所有功能提供端点.这允许应用从 Spotify 音乐目录中获取数据并管理用户的播放列表和保存的音乐.

Many apps expose interfaces to their information in the form of an API (application program interface). For example, the Spotify API provides endpoints for almost all of its functionality. This allows applications to fetch data from the Spotify music catalog and manage user’s playlists and saved music.

由于这些外部请求可能会淹没服务并访问用户信息，因此需要使用身份验证来保护它们.

Since these external requests could overwhelm a service and also access user information, they need to be secured using authentication.

从另一个应用程序访问 API 的最基本模式是使用 API 密钥.

The most basic pattern for API access from another application is using an API key.

公共 API 通常提供一个开发者门户，您可以在其中注册您的应用程序并生成相应的 API 密钥.此密钥对您的应用程序来说是唯一的.当您的应用程序发出请求时，此密钥会随之发送.然后，API 可以验证您的应用是否被允许访问，并根据您的应用的权限级别提供正确的响应.

Public APIs usually provide a developer portal where you can register your application and generate a corresponding API key. This key is then unique to your application. When your application makes a request, this key is sent along with it. The API can then verify that your application is allowed access and provide the correct response based on the permission level of your application.

API 可以跟踪每个应用程序发出的请求的类型和频率.此数据可用于将来自特定应用程序的请求限制到预定义的服务级别.这可以防止应用向端点发送垃圾邮件或滥用用户数据，因为 API 可以轻松阻止该应用的 API 密钥并防止该应用进一步恶意使用该 API.

The API can track what type and frequency of requests each application is making. This data can be used to throttle requests from a specific application to a pre-defined level of service. This prevents applications from spamming an endpoint or abusing user data, since the API can easily block that application's API key and prevent further malicious use of the API by that application.

OAUTH

对于许多应用程序，通用的开发人员级 API 密钥是不够的.如前所述，API 有时能够提供对用户级数据的访问.但是，大多数服务仅在用户启用时才提供此私人数据.

For many applications, a generic developer-level API key is not sufficient. As mentioned earlier, APIs sometimes have the ability to provide access to user-level data. However, most services only provide this private data if the user enables it.

例如，Facebook 不希望 Tinder 访问其所有用户的数据，只希望那些选择允许共享数据以更好地帮助他们在其所在地区找到匹配项的用户.

For example, Facebook doesn't want Tinder to access all of their users' data, just the users who have opted in to allowing the sharing of data to better help them find a match in their area.

解决此问题的基本方法可能是让用户向中间应用程序提供他们的登录凭据，但这不是很安全，并且会授予对请求应用程序的完全访问权限，此时请求应用程序可能只需要非常有限的一组运行权限.

A basic approach to this problem might be to have the user provide their login credentials to the intermediary application, but this is not very secure and would give full access to the requesting application, when the requesting application might only need a very limited set of privileges to function.

OAuth 定义了一种更优雅的方法来解决这个问题.它由 Twitter 首席开发人员 Blaine Cook 于 2006 年 11 月开发，1.0 版于 2010 年 4 月发布.

OAuth defines a more elegant approach to this problem. It was developed in November 2006 by lead Twitter developer Blaine Cook and version 1.0 was published in April 2010.

OAuth 是一种开放标准，通常用于授予应用程序访问用户信息的权限，而不会强迫用户泄露密码.

OAuth is an open standard and is commonly used to grant permission for applications to access user information without forcing users to give away their passwords.

开放标准是对某些功能应该如何工作的公开定义.但是，该标准实际上并未构建该功能.

An open standard is a publicly available definition of how some functionality should work. However, the standard does not actually build out that functionality.

因此，每个 API 都需要实现自己的 OAuth 版本，因此实现或流程可能略有不同.但是，它们都基于相同的 OAuth 规范.

As a result, each API is required to implement their own version of OAuth and therefore may have a slightly different implementation or flow. However, they're all based around the same OAuth specification.

这会使使用新的 OAuth API 更加令人沮丧.但是，随着时间的推移，您将开始注意到 API 身份验证流程之间的相似性，并能够越来越轻松地在您的应用程序中使用它们.以下是标准 OAuth 流程的摘要.

This can make using a new OAuth API a little more frustrating. However, with time you will begin noticing the similarities between API authentication flows and be able to use them in your applications with increasing ease. Below is a summary of the standard OAuth flow.

通用 OAUTH 流程

GENERIC OAUTH FLOW

许多实施 OAuth 的应用程序会首先要求用户选择他们想要使用的凭据服务:

Many applications implementing OAuth will first ask the user to select which service they would like to use for credentials:

使用 Google、Facebook 或 Twitter 登录

Login with Google, Facebook or Twitter

选择服务后，用户将被重定向到该服务进行登录.此登录确认用户的身份，通常会向用户提供原始应用程序试图在用户帐户上获得的权限列表.

After selecting the service, the user will be redirected to the service to login. This login confirms the user’s identity and typically provides the user with a list of permissions the originating application is attempting to gain on the user’s account.

如果用户确认他们想要允许此访问，他们将被重定向回原始站点以及访问令牌.此访问令牌随后由原始应用程序保存.

If the user confirms they want to allow this access, they will be redirected back to the original site, along with an access token. This access token is then saved by the originating application.

与开发人员 API 密钥一样，此访问令牌将包含在应用程序的请求中，以证明用户已授予访问权限并允许该用户访问适当的内容.当用户返回应用程序时，将检索令牌，而无需重新进行身份验证.

Like a developer API key, this access token will be included on requests by the application to prove that the user has granted access and enable access to the appropriate content for that user. When a user returns to the application, the token will be retrieved and they will not have to re-authenticate.

OAUTH 2

由于 OAuth 是从 Twitter 演变而来的，因此有一些重要的用例最初并未被视为规范的一部分.最终，这导致创建了新版本的规范，称为 OAuth 2.

Since OAuth evolved out of Twitter, there were important use cases not originally considered as part of the specification. Eventually, this led to the creation of a new version of the specification, called OAuth 2.

在其他改进中，OAuth 2 允许根据请求访问的特定应用程序和请求的访问级别进行不同的身份验证流程.

Among other improvements, OAuth 2 allows for different authentication flows depending on the specific application requesting access and the level of access being requested.

OAuth 2 仍然是一个开放标准，因此每个 API 都将根据其特定实现拥有自己的流程.下面，我们将讨论一些常见的 OAuth 2 流程及其使用方式.

OAuth 2 is still an open standard, so each API will have its own flow based on its particular implementation. Below, we’ll discuss a few of the common OAuth 2 flows and how they are used.

客户凭据授予

有时应用程序不需要访问用户信息，但可以实现 OAuth 2 规范的附加安全性和一致性.此类授权用于访问应用级数据(类似于上面的开发者 API 密钥)，最终用户不参与此流程.

Sometimes an application will not need access to user information but may implement the added security and consistency of the OAuth 2 specification. This type of grant is used to access application-level data (similar to the developer API key above) and the end user does not participate in this flow.

代替 API 密钥，客户端 ID 和客户端密钥(当应用程序被授权使用 API 时提供给应用程序的字符串)被交换为访问令牌(有时是刷新令牌).稍后我们将更深入地讨论刷新令牌.

Instead of an API key, a client ID and a client secret (strings provided to the application when it was authorized to use the API) are exchanged for an access token (and sometimes a refresh token). We will discuss refresh tokens in more depth later.

此流程类似于我们的第一个示例，其中将电子邮件和密码交换为身份验证令牌.

This flow is similar to our first example, where an email and password were exchanged for an authentication token.

确保客户端机密不会像密码一样成为公开信息至关重要.因此，开发人员应该小心不要意外地将此信息提交到公共 git 存储库.此外，为确保密钥的完整性，不应在客户端公开它，并且所有包含它的请求都应发送到服务器端.

与前面提到的密钥类似，返回的访问令牌包含在请求中，用于识别发出请求的客户端，并受 API 限制.

Similar to the previously-mentioned keys, the returned access token is included on requests to identify the client making the requests and is subject to API restrictions.

此访问令牌通常是短暂的，经常过期.到期后，可以通过重新发送客户端凭据或最好是刷新令牌来获取新的访问令牌.

This access token is often short-lived, expiring frequently. Upon expiration, a new access token can be obtained by re-sending the client credentials or, preferably, a refresh token.

刷新令牌是 OAuth 2 更新的一个重要特性，它鼓励访问令牌经常过期并因此不断更改(在原始 OAuth 规范中，访问令牌可以持续数年的时间段).当刷新令牌用于生成新的访问令牌时，它通常会使任何以前的访问令牌过期.

Refresh tokens are an important feature of the OAuth 2 updates, encouraging access tokens to expire often and, as a result, be continuously changed (in the original OAuth specification, access tokens could last for time periods in the range of years). When a refresh token is used to generate a new access token, it typically expires any previous access tokens.

授权代码授予

此流程是 OAuth 最常见的实现之一，如果您曾经使用 Google 或 Facebook 登录过网络应用程序，您就会很熟悉.它类似于前面描述的 OAuth 流程，但增加了一个步骤，将请求应用程序与身份验证联系起来.

This flow is one of the most common implementations of OAuth and will look familiar if you’ve ever signed into a web application with Google or Facebook. It is similar to the OAuth flow described earlier with an added step linking the requesting application to the authentication.

用户被重定向到身份验证站点，验证请求访问和权限的应用程序，然后使用授权代码重定向回引用站点.

A user is redirected to the authenticating site, verifies the application requesting access and permissions, and is redirected back to the referring site with an authorization code.

请求应用程序然后获取此代码并将其连同应用程序的客户端 ID 和客户端密钥提交给身份验证 API，以接收访问令牌和刷新令牌.然后，此访问令牌和刷新令牌的使用方式与前一个流程相同.

The requesting application then takes this code and submits it to the authenticating API, along with the application’s client ID and client secret to receive an access token and a refresh token. This access token and refresh token are then used in the same manner as the previous flow.

为了避免暴露客户端 ID 和密码，流程的这一步应该在请求应用程序的服务器端完成.

To avoid exposing the client ID and secret, this step of the flow should be done on the server side of the requesting application.

由于令牌同时与用户和请求应用程序相关联，因此 API 可以根据用户行为、应用程序行为或两者对限制访问进行大量控制.

Since tokens are tied both to users and requesting applications, the API has a great deal of control over limiting access based on user behavior, application behavior, or both.

隐性授权

前两种方法导致客户端秘钥被暴露，所以需要在服务端处理.某些应用程序可能需要访问 OAuth API，但没有必要的服务器端功能来保证这些信息的安全.

The previous two methods cause the client secret key to be exposed, so they need to be handled server-side. Some applications may need to access an OAuth API but don't have the necessary server-side capabilities to keep this information secure.

隐式授予 OAuth 流程就是为这个用例设计的.此流程通过与授权代码流程类似的授权步骤提示用户，但不涉及客户端机密的交换.

The Implicit Grant OAuth flow was designed for this very use case. This flow prompts the user through similar authorization steps as the Authorization Code flow, but does not involve the exchange of the client secret.

此交互的结果是访问令牌，通常没有刷新令牌.然后应用程序使用访问令牌向服务发出其他请求，但不会发送到请求应用程序的服务器端.

The result of this interaction is an access token, and typically no refresh token. The access token is then used by application to make additional requests to the service, but is not sent to the server side of the requesting application.

此流程允许应用程序使用 OAuth API，而不必担心可能会暴露对用户或应用程序信息的长期访问权限.

This flow allows applications to use OAuth APIs without fear of potentially exposing long-term access to a user or application's information.

结论

OAuth 提供对各种网站和信息的强大访问.通过正确使用它，您可以在您的应用中减少注册摩擦并丰富用户体验.

OAuth provides powerful access to a diverse set of sites and information. By using it correctly, you can reduce sign-up friction and enrich user experience in your applications.

这篇关于有没有办法保护 React JS 中的 API 密钥，即使它在客户端?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！