如何处理 OAuth2 客户端 ID 和密码? [英] How to deal with OAuth2 client id and secret?

问题描述

我想用 Spring Boot 实现 OAuth2.我看到了最大的演示，他们使用了硬编码的客户端 ID 和密码.在实际项目中，我们如何使用这些?

I want to implement OAuth2 with Spring Boot. I saw maximum demo, they had used hard coded client id and secret. In a real project, how do we use these?

我附上了两张图片.一个是客户端代码，我使用 Angular 制作，另一个是服务器代码，使用 Spring Boot OAuth2 制作.

I am attaching two images. One is of client code, I have made it using Angular, another one is server code, made it with Spring Boot OAuth2.

推荐答案

您可以在客户端(属性文件、数据库、JNDI、...)保存您的客户端 ID，因为它是一个公共标识符，请参阅 RFC 6749:

You can save your client ID on client-side (property file, database, JNDI, ...), because it is a public identifier, see RFC 6749:

2.2.客户标识符

授权服务器向注册的客户端发出一个客户端标识符——一个代表客户端提供的注册信息的唯一字符串.客户端标识符不是秘密；它向资源所有者公开，不得单独用于客户端身份验证.客户端标识符对于授权服务器是唯一的.

The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client. The client identifier is not a secret; it is exposed to the resource owner and MUST NOT be used alone for client authentication. The client identifier is unique to the authorization server.

您可以在客户端(属性文件、数据库、JNDI 等)保存您的客户端机密，如果您有机密客户端，请参阅 RFC 6749:

You can save your client secret on client-side (property file, database, JNDI, ...), if you have a confidential client, see RFC 6749:

2.1.客户类型

OAuth 定义了两种客户端类型，基于它们与授权服务器进行安全身份验证的能力(即维护其客户端凭据机密性的能力):

OAuth defines two client types, based on their ability to authenticate securely with the authorization server (i.e., ability to maintain the confidentiality of their client credentials):

• 机密
  能够维护其凭据机密性的客户端(例如，在安全服务器上实现的客户端对客户端凭据的访问受到限制)，或能够使用其他方式进行安全的客户端身份验证.

• confidential
  Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

公开
客户端无法维护其凭据的机密性(例如，在资源所有者使用的设备上执行的客户端，例如已安装的本机应用程序或基于 Web 浏览器的应用程序)，并且无法通过任何其他方式进行安全的客户端身份验证.

public
Clients incapable of maintaining the confidentiality of their credentials (e.g., clients executing on the device used by the resource owner, such as an installed native application or a web browser-based application), and incapable of secure client authentication via any other means.

对于不需要身份验证的公共客户端，请参阅RFC 6749:

For public clients you need no authentication, see RFC 6749:

2.3.客户端身份验证

[...]授权服务器可以与公共客户端建立客户端身份验证方法.但是，授权服务器不得依赖公共客户端身份验证来识别客户端.

[...] The authorization server MAY establish a client authentication method with public clients. However, the authorization server MUST NOT rely on public client authentication for the purpose of identifying the client.

但并非所有授权服务器都支持授权代码授予的公共客户端.

But not all authorization servers are supporting public clients for Authorization Code Grant.

另一种方法是使用隐式授权(没有客户端密码)，参见 RFC6749:

Another way is to use the Implicit Grant (without a client secret), see RFC 6749:

4.2.隐式授权

隐式授权类型用于获取访问令牌(它不支持发布刷新令牌)，并针对已知操作特定重定向 URI 的公共客户端进行了优化.这些客户端通常使用 JavaScript 等脚本语言在浏览器中实现.

The implicit grant type is used to obtain access tokens (it does not support the issuance of refresh tokens) and is optimized for public clients known to operate a particular redirection URI. These clients are typically implemented in a browser using a scripting language such as JavaScript.

[...]

隐式授权类型不包括客户端身份验证，并依赖于资源所有者的存在和重定向 URI 的注册.由于访问令牌被编码到重定向 URI 中，因此它可能会暴露给资源所有者和驻留在同一设备上的其他应用程序.

The implicit grant type does not include client authentication, and relies on the presence of the resource owner and the registration of the redirection URI. Because the access token is encoded into the redirection URI, it may be exposed to the resource owner and other applications residing on the same device.

但并非所有授权服务器都支持隐式授权，例如 GitHub.

But not all authorization servers are supporting Implicit Grant, for example GitHub.

这篇关于如何处理 OAuth2 客户端 ID 和密码?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！