我们有一个基于 OAuth2 的身份验证基础设施，该基础设施已集成到我们组织内的各种 Web 应用程序中。我们还有一个没有自己的中间件的纯原生应用程序，我们希望将身份验证集成到这个原生应用程序中。这个应用程序已经有自己的内部登录机制和一个本地登录屏幕，我们不希望它启动外部组件，如 Web 浏览器来显示登录窗口。我们是应用提供商和权威性提供两个，因此具有可识别性应用的关注到用户的凭据是少一个问题-我们相信自己，不刻意用用户的凭据做任何不妥当的事情，在应用程序中编写登录表单和在网站上编写登录表单的人是同一个人。:-)
我们试图找出如何最好地支持应用程序继续以现在的方式收集凭据，但使用它们在我们的身份验证框架内获取身份验证令牌。现在有了 API，我可以看到要完成的唯一方法是将客户端机密烘焙到本机应用程序中，以便它可以使用资源所有者密码凭据授予请求，因为通常会制作的代码这个调用没有服务器端可以居住。不知何故，这感觉真的很不对。:-P
据我所知，OAuth 的许多结构并不真正适用于这个应用程序，因为它不存在于 Web 浏览器的上下文中，它没有任何“域”的概念，也没有任何形式的“跨域”限制。有人建议也许我们只是为这个应用程序创建中间件用于交换令牌的身份验证代码，但其基本原理似乎是该中间件理论上应该能够以某种方式审查请求以确定它们是否合法地来自应用程序，我看不到任何方法任何有权访问客户端应用程序代码的人都无法伪造。基本上，此类中间件的唯一目的是使客户端机密与获取凭据的身份验证代码无关。
我们想到的一个想法是，像 Windows 这样的东西是如何做到的？Windows 很明显使用本机登录表单，但随后存在一些流程，其中输入的凭据用于身份验证，并且可能在操作系统内部深处用于获取身份验证令牌。有人知道这种架构是否在任何地方都有记录吗？微软在这里的架构选择与 OAuth2 有什么关系吗？什么是“最佳实践”为应用程序，如果你把它作为一个给定的，它并没有中间件，有其自己的本机登录表单？
如果我创建一个堆表并将一堆行放入其中，则每一行在数据文件中都有一个物理位置，并有一个指向该行的指针，但是它没有结构，除了精确的指针之外，无法查找任何内容到给定的行。
如果再创建一个非聚集索引，则该记录按照某种条件对这些行进行排序，那么该索引将为每一行包含其正在排序的键，我明确包括的所有列以及行指针，以便在其中查找记录时一种与索引兼容但需要索引中不包含列的方式，它确切地知道获取数据的位置，对吗？
假设这是正确的，我想了解的是：如果我然后在表上创建聚簇索引，那么堆将被重新组织，以便按聚簇索引的键对记录进行排序。这意味着可能每条记录的物理位置都会发生变化。预先存在的非聚集索引中的行指针如何跟踪它？
如果有所作为，我将使用SQL Server作为基础引擎。