我目前正在从事个人项目,在 Rust 中为 OAuth 2.0 协议实现授权服务器。具体来说,我正在尝试使用 PKCE、设备代码流和客户端凭证流来实现授权代码流。在大多数情况下,我有端点路由设置和数据库表设置来存储信息,并且能够足够轻松地设置客户端凭据授权。
但是,当在线阅读有关授权代码和设备代码流的帖子时,我注意到我认为对于用户在授权服务器上进行身份验证和授予权限的步骤来说是一种“手摇”。我知道授权服务器应该向用户显示一些登录提示,以及现有的身份提供者,如 Okta、Google 等。我相信提示通常是一个网页,要求用户提供他们的电子邮件/用户名和密码。
因此,我设置了一个 Users DB 表,并创建了一些 Yew 网页以促进此提示,但是对于此提示与代码授权之间应该建立的连接感到困惑。以下是我对通常/应该发生的事情的猜测:
由此产生的两个主要问题:
首先也是最重要的是这个流程听起来/看起来是否正确。它主要来自观察 oauth 游乐场流程,以及我所知道的现有身份提供者的文档/流程。
第二个是,假设这个流程是正确的,是否有某种方法可以通过授权服务器的登录提示来识别经过身份验证的用户,而无需专门为提示流程实施身份验证服务?我最终还计划将 OpenID Connect 功能添加到授权服务器,因为这是我首先制作授权服务器的主要原因之一。感觉很傻,为了允许 oauth 2.0 授权,我需要实现一个基本/“不太安全”的身份验证系统(我知道 oauth 用于授权,这里指的是提示身份验证系统不如 OpenID Connect 安全) 只是为了允许用户授权并最终进行身份验证。因此,我觉得我在这里遗漏了一些东西。
尝试的操作 我试图观察现有身份服务提供商的一些 OAuth 流程,以及阅读 OAuth 2.0 的 RFC,更具体地说是授权代码和设备代码流程,最后在线研究该主题无济于事。
此外,我正在考虑在我的授权服务器的代码提示流程中添加一个身份验证系统,以允许用户登录并授权代码流程,但如上所述,这似乎不对,想确认这是正确的路线在继续前进之前。
相关链接
互动资源:
RFC
谷歌搜索结果:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
Microsoft OAuth 授权代码流程概述
https://developer.okta.com/blog/2018/04/10/oauth-authorization-code-grant-type
OAuth 授权代码流程的 Okta 概述