在两个网站之间共享身份验证

发布于 2024-11-25 06:05:16 字数 307 浏览 1 评论 0原文

在两个站点之间共享登录的最佳/正确技术是什么?

我有网站 A 和一些网站 B。这两种类型都属于同一家公司,但 B 运行在客户端。我想要的是,用户在B中登录,当由于某种原因重定向到A时,他们不需要再次登录,并且可以使用他们在A中的帐户。

当然,公司将为每个用户进行登录“B”用户。问题是用户可以在 A 或 B 中发起登录。OAuth

可以吗?或者OpenID会更合适?

另一种选择是在 GET 字符串中传递 GUID 令牌,具有排序生存时间,并且仅对请求者的 IP 地址有效,但不确定用户是否会通过同一网关访问网站。

谢谢

What is the best/proper technique to share login between two sites.

I have website A, and some websites B. Both types belong to the same company, but B is running on the customer premises. What I would like, is that users login in B, and when redirected to A for some reason, they don't need to login again, and they can work with their account in A.

Of course, the company will make logins for each 'B' user. The problem is that the user could initiate the login in A or B.

Would OAuth do? Or OpenID would be more suitable?

Another option is pass a GUID token in the GET string, with a sort time to live and only valid for the IP address of the requester, but it is not sure the user would access the web sites through the same gateway.

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

韶华倾负 2024-12-02 06:05:16

OAuth 正是您所需要的。 OpenID 提供发现功能,仅当用户选择向谁进行身份验证(而不是您的用例)时才有用。此外,OpenID 更为复杂,并且是一个即将消亡的协议。

在您的场景中,服务器 A 是 OAuth 服务器(或 OAuth 2.0 中的授权服务器),服务器 B 是客户端。有很多方法可以实现这一点,但我建议您首先查看(并尝试)Facebook OAuth 2.0 实现的工作原理。它会让您很好地了解所涉及的内容以及它们的一些扩展(例如显示),这使得它更加用户友好。

OAuth is exactly what you need. OpenID offers discovery which is only useful when the user gets to choose who to authenticate with (not your use case). Also, OpenID is much more complicated and is a dying protocol.

In your scenario, Server A is the OAuth server (or authorization server in OAuth 2.0) and Server B is the client. There are many ways to implement this, but I would suggest you start by looking (and trying) how Facebook OAuth 2.0 implementation works. It will give you a good idea of what is involved and some of their extension (e.g. display) which make it more user-friendly.

娇妻 2024-12-02 06:05:16

您正在谈论单点登录。拥有网站 A 的公司是否在其 api 中提供远程登录?

您需要确保登录信息在传递到网站 A 时是加密的。我构建的最后一个单点登录要求我传递通过 RSA 加密并使用 MD5 散列的用户 AD 名称。第三方拥有用户 AD 名称及其第三方网站密码的数据库。当用户点击链接时,他们的加密信息被发送到第三方的登录API,第三方将他们重定向到欢迎页面,登录过程完成。

如果您自己构建单点登录 API,例如您可以控制网站 A,那么 OAuth 是一个不错的选择。实施起来相当容易。

You are talking about single sign-on. Does the company who owns Website A provide remote sign-on in their api?

You need to make sure that the log-on information is encrypted when it is passed to website A. The last single sign-on I built required me to pass the user's AD name encrytped via RSA and hashed with MD5. The third party had a database of the user's AD name and their password to the third party site. When the user clicked a link, their encrypted information was sent to the log-on api of the third party and the third party redirected them to the welcome page with the log on process complete.

If you are building a single sign-on API yourself, as in you have control over website A, OAuth is a respectable choice. It is fairly easy to impliment.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文