我正在寻找一些示例、提示、建议以及一些实现（或寻找实现）面向方面的 HTTP 身份验证库的一般方向感。
作为一些基础工作，我们构建了一个 iOS 库，它为 HTTP 服务建立了各种形式的身份验证，根据使用的机制，通过 Web 表单或本机模式窗口请求用户凭据。但是一旦凭证被验证，图书馆就会把它们交给他们，并且基本上会抹去它确保会话新鲜度、超时等的任何责任。
我有兴趣找到示例，或在我们的应用程序和后端服务之间实现更多连续网络身份验证网关的一些指导。从某种意义上说，应用程序为此身份验证库进行了一些初始配置，从那时起，任何 NSURLConnections 或 UIWebView 请求都将被透明地拦截并通过此身份验证库...库接收这些请求，确定是否存在有效身份验证会话满足要求或是否通过网络表单或本机模式为这些待处理的请求中的一个或多个呈现登录......然后一旦满足，它将结果响应汇集回初始请求者。
重要的是，后续的网络请求都不想或不需要知道有关正在使用的身份验证机制的任何特殊细节，无论是 cookie、Basic Auth 标头、O-Auth 令牌等......任何这些细节都由auth 库，因为它会改变出站请求并监听入站响应。
我很确定如果我们实现了一个 NSURLProtocol，我们可以通过这个库重定向连接，但是我理解这需要 URL 有一个自定义方案是否正确？（即 myauthlib-https://）...这似乎打破了后续连接不需要知道任何关于任何身份验证实现的特殊信息的要求。理想情况下，对 http:// 和 https:// 的任何 GET、POST、PUT、DELETE、PATCH 请求都将自动透明地通过此出站/入站身份验证...
我们可以尝试一些在 NSURLConnection 上调配的方法来通过我们的 auth 库重定向它，但这似乎相当脆弱。我也在考虑实现基于AOP-for-Objective-C 的东西
尝试以编程方式实现 HTTP 代理会更明智吗？