MDM 管理的 iOS 设备上的推荐身份验证流程
Recommended authentication flow on MDM managed iOS devices
我们正在构建一个 iOS 本机应用程序和两个网络应用程序。对于 identiy/access 管理，我们使用 Keycloak（支持 OpenID Connect 和 OAuth 2.0）。
iOS 个应用安装在 MDM 管理的设备上。只安装了我们的应用程序。
我了解到，目前实施 authentication/authorization 的最佳做法是使用 OpenId Connect 和通过外部用户代理的基于浏览器的流程：
- http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007259.html
- https://www.rfc-editor.org/rfc/rfc8252.txt
- https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
使用这些库之一：
是否也建议 MDM 管理的 iOS 设备（没有 "evil" 第三方应用程序，只有我们自己的东西）实现基于浏览器的流程？或者在这种情况下实现本机登录流程是否安全（用户直接在应用程序中输入凭据）？
我担心用户体验...我们的应用程序和浏览器之间的切换看起来不是很流畅...
有一个关于 OAuth2 for native apps 的 RFC。值得一读——它讨论了可能的实现和涉及的安全风险。一般推荐的方法是在浏览器（而不是内部应用程序组件）中使用授权代码流，因为这样应用程序无法获取用户凭据。人们习惯于比其他应用更信任浏览器和身份验证提供程序，因此 URL 和经过验证的 SSL 证书的可见性也很重要。
RFC 还涵盖了 iOS implementation details:
Apps can initiate an authorization request in the browser, without the
user leaving the app, through the "SFSafariViewController" class or
its successor "SFAuthenticationSession", which implement the in- app
browser tab pattern. Safari can be used to handle requests on old
versions of iOS without in-app browser tab functionality.
因此，如果您使用 SFAuthenticationSession，则无需打开新的 Safari window，用户体验应该不会受到影响。
如果您使用 Resource Owner Password Credentials grant（用户将他们的凭据直接输入您的应用程序），出于同样的原因，您将降低它的安全性 - 凭据会暴露给应用程序。并且使用此授权，您不能在 Keycloak（Google、Facebook）中使用第三方身份验证提供程序。
这取决于你（和你的组织）你希望系统有多安全，所以你可以选择一些妥协，但我宁愿坚持当前的最佳实践，因为应用程序可能会在以后增长妥协可能会变成问题。
我们正在构建一个 iOS 本机应用程序和两个网络应用程序。对于 identiy/access 管理，我们使用 Keycloak（支持 OpenID Connect 和 OAuth 2.0）。
iOS 个应用安装在 MDM 管理的设备上。只安装了我们的应用程序。
我了解到，目前实施 authentication/authorization 的最佳做法是使用 OpenId Connect 和通过外部用户代理的基于浏览器的流程：
- http://lists.jboss.org/pipermail/keycloak-dev/2016-May/007259.html
- https://www.rfc-editor.org/rfc/rfc8252.txt
- https://auth0.com/blog/oauth-2-best-practices-for-native-apps/
使用这些库之一：
是否也建议 MDM 管理的 iOS 设备（没有 "evil" 第三方应用程序，只有我们自己的东西）实现基于浏览器的流程？或者在这种情况下实现本机登录流程是否安全（用户直接在应用程序中输入凭据）？
我担心用户体验...我们的应用程序和浏览器之间的切换看起来不是很流畅...
有一个关于 OAuth2 for native apps 的 RFC。值得一读——它讨论了可能的实现和涉及的安全风险。一般推荐的方法是在浏览器（而不是内部应用程序组件）中使用授权代码流，因为这样应用程序无法获取用户凭据。人们习惯于比其他应用更信任浏览器和身份验证提供程序，因此 URL 和经过验证的 SSL 证书的可见性也很重要。
RFC 还涵盖了 iOS implementation details:
Apps can initiate an authorization request in the browser, without the user leaving the app, through the "SFSafariViewController" class or its successor "SFAuthenticationSession", which implement the in- app browser tab pattern. Safari can be used to handle requests on old versions of iOS without in-app browser tab functionality.
因此，如果您使用 SFAuthenticationSession，则无需打开新的 Safari window，用户体验应该不会受到影响。
如果您使用 Resource Owner Password Credentials grant（用户将他们的凭据直接输入您的应用程序），出于同样的原因，您将降低它的安全性 - 凭据会暴露给应用程序。并且使用此授权，您不能在 Keycloak（Google、Facebook）中使用第三方身份验证提供程序。
这取决于你（和你的组织）你希望系统有多安全，所以你可以选择一些妥协，但我宁愿坚持当前的最佳实践，因为应用程序可能会在以后增长妥协可能会变成问题。