我一直在阅读不同的OAuth授权流程，以更好地理解如何保护我的应用程序，也许还可以滚动自己的示例OAuth / OIDC / Single-Sign-On提供程序来了解Okta / Auth0库涵盖的某些抽象。
虽然我了解一般的请求流程，但是在区分Client，Browser和Resource Server时遇到很多困难。
我正在想象一个传统的SPA，它由包含应用程序自己的SPA的相同域和存储库提供服务。因此，一个Express / NodeJS应用程序包含CRUD端点，并且能够为html / js应用程序提供服务以访问这些端点。
根据OAuth最佳做法，具有用户凭据的身份验证服务器应托管在其他域上，并具有自己的专用数据库。
要使用我的应用程序登录，用户将被重定向到由单独的身份验证提供程序域提供服务的登录页面。
据我了解，这里的隐式流程就足够了，在我的身份验证服务器验证了客户端凭据之后，将在哈希URL参数中包含我的access_token的302响应发送回我的应用程序。
https://my-app/callback
#access_token=ey123AsMhPw...
&expires_in=7200
&token_type=Bearer
&id_token=mA8s1#3...
这使我想到了第一个问题：
为什么访问令牌直接在回调URI中公开？
我的应用程序应从URL解析访问令牌，并将其存储在会话存储中，而我认为最佳实践是始终将访问令牌发送到 HTTPonly安全Cookie
在这种情况下，不发送刷新令牌。但是，如果要实现SSO，则需要在客户端浏览器和身份验证域之间使用基于cookie的标识符，因此，即使我想在此示例中使用“隐式流”，我也希望能够从第二次登录应用程序并标识用户-但“隐式流程”不允许发送刷新令牌，那么Auth Server是否只生成一个随机标识符字符串作为cookie？
我应该改为使用授权码流吗？
Current Best Practices Suggest Securing SPA with PKCE Authorization Code Flow
同样，将客户端发送到第三方身份验证域提供的登录页面。必须发送几个标识符，以确保从受信任的应用程序进行登录尝试。服务SPA的服务器还将client_id和client_secret存储在某些隐藏的源代码中，例如.env文件。
https://authorization-server.com/auth-login
?response_type=code
&client_id=CLIENT_ID
&redirect_uri=REDIRECT_URI
&scope=photos
&state=1234zyx
如果这是我的原始示例应用程序，则Auth Server将提供登录页面。 如果这是利用SSO的辅助应用程序，则Auth Server将已经具有客户端标识符，而将出现诸如
的屏幕 Do you wish to allow App 2 to access your data? Example App 1 will share your name and email address
在两种情况下，如果用户登录或授权使用其原始应用程序数据，都会生成authorization code并将其存储在Auth DB中。此代码也作为重定向发送回客户端。
https://example-app.com/REDIRECT_URI
?code=abcdefg
&state=1234zyx
这是我的主要问题，谁将完全使用此信息并将请求发送到/token端点，以将访问授权令牌交换为访问令牌？是我的Web App后端，还是前端/浏览器？
我认为它必须是后端，因为响应以纯JSON格式出现，并且令牌终结点需要CLIENT SECRET 令牌请求
POST
https://authorization-server.com/token
?grant_type=authorization_code
&code=abcdefg
&redirect_uri=/you-are-now-logged-in/
&client_id=...
&client_secret=...
令牌响应：
{
"access_token":"MTQ0NjJkZmQ5OTM2NDE1ZTZjNGZmZjI3",
"token_type":"bearer",
"expires_in":3600,
"refresh_token":"IwOGYzYTlmM2YxOTQ5MGE3YmNmMDFkNTVk",
"scope":"create delete"
}
该信息如何由Web应用程序后端存储和管理？
最佳做法是将令牌作为HTTPONLY SECURE COOKIES发送回。 Auth Server应该包含所有用户权限和范围，不需要针对数据库检查自包含的JWT，所有API端点都可以通过中间件解码JWT并直接读取权限，从而确定给定用户是否能够进行各种保护路线。
但是，最佳做法还说 切勿将刷新令牌发送到资源服务器
如果我的SPA / Web应用程序使用此流来请求访问令牌以访问其自己的自托管终结点，该怎么办？响应刚刚发回了刷新令牌。我认为只能访问刷新令牌的参与方是客户端（Web浏览器）和身份验证服务器（通过cookie？）
是否最好避免将令牌作为cookie完全发送回Web浏览器，并将刷新令牌和访问令牌作为加密会话存储在Web应用程序后端服务器上？ >
对于这个长期的问题，我深表歉意，感谢您对任何这些问题的帮助，如果有任何试图构建OICD / OAuth身份提供者的存储库/源代码，我想读一遍，谢谢您需要任何帮助。