- keycloak-client 的访问类型应该是公开的还是保密的?
从RFC 6749 OAuth 2.0 specification可以阅读:
机密
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.
公开
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
由于您使用的不是纯网络浏览器应用程序或手机,而是具有安全后端的网络应用程序,因此您应该使用@987654325 @。
即客户端密码是做什么用的? (加密)?
来自 Keycloak 文档:
机密客户需要提供客户机密
用临时代码交换令牌。公共客户不是
需要提供此客户端密码。
因此,您需要client-secret,因为您选择了confidential client。使用 client-secret 以便可以正确验证从 Keycloak 请求访问令牌的应用程序。在您的情况下,来自公司的服务器(使用您的应用程序)从 Keycloak 请求访问令牌。因此,Keycloak 必须确保发出请求的服务器是合法。
这就是client-secret 的目的。这类似于当您去 ATM 取款时,如果您已插入,银行知道您是该资源的所有者(即银行帐户)正确的代码(即,类似于客户端密码)。
如果公司管理员理论上可以
通过反编译我给他们的客户端应用程序的 jar 来读取秘密?
请求令牌的应用程序(即公司)和授权服务器(即 Keycloak)必须知道client_secret。所以理论上,如果公司不介意他们的管理员可以访问这些信息,那对你来说应该没问题。归根结底,client-secret 无论如何都必须为双方所知。缓解客户端机密泄露的潜在问题的一种方法是不时更改客户端机密,并将该更改传达给相关方。
只要一家公司不能对另一家公司的客户机密进行逆向工程,就可以了。
这种情况下的重定向 URI 可以是什么?
用户认证成功后,应该是部署客户端应用的公司前端首页的URL。
但请记住:
在注册有效的重定向 URI 时应采取额外的预防措施
模式。如果你让它们太笼统,你很容易受到攻击。
有关详细信息,请参阅威胁模型缓解章节。
(source)