无论如何，即使在客户端，React JS中是否也有安全的API密钥? [英] Is there anyway to secure API keys in React JS, even though it's on the client side?

问题描述

在React javascript文件上使用API​​密钥时，是否仍然需要保护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如何进行纯客户端身份验证:

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

对使用API​​密钥，OAuth等进行身份验证的一般介绍(来源:关于构建Web应用程序的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.

通常，成功登录后，应用程序将使用身份验证令牌(或auth令牌)进行响应，以供客户端用于其他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月开发，并于2010年4月发布了1.0版.

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的应用程序会首先要求用户选择他们要用于凭据的服务:

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.

使用客户端ID和客户端密钥(授权使用API​​的应用程序提供的字符串)代替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.

Implicit Grant 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屋！