是的，你的理解是正确的.为了在移动客户端上使用 SAML IDP，您需要执行与普通客户端相同的过程(AuthnRequest -> SP 和 IDP 之间的响应交换).整个流程可能如下所示:

Yes, your understanding is correct. In order to use SAML IDP with mobile clients you need to go through the same process as on normal clients (AuthnRequest -> Response exchange between SP and IDP). The whole flow can look like this:

• 您的移动应用程序打开 WebView，访问您的 SP 的公共 URL
• 您的 SP 通过使用 AuthnRequest 向 SAML IDP 发送重定向，开始使用 IDP 进行身份验证
• 用户在 IDP 的 UI 内进行身份验证(当它使用移动客户端打开时，它应该能够为移动客户端正确呈现)
• IDP 通过响应重定向回您的 SP
• 您的 SP 应用程序处理响应并生成可用于您的 Rest API 的令牌
• SP 将令牌传递回移动应用程序(例如，使用 WebViewClient + onPageFinished + cookie，或调用 addJavascriptInterface 提供的对象，或您已经使用的任何内容)

与通常使用 IDP 的移动身份验证(例如对 Facebook/Google 使用 OAuth 2)相比，SAML 更为复杂.使用 OAuth 2.0，可以轻松提取授权令牌并使用自定义 URL 方案拦截响应，而无需 Web 部署 (SP) 组件.由于 SAML 不支持类似于 Oauth 中的隐式"流(出于安全原因)，并且由于 SAML 响应的处理要复杂得多(由于 XML 签名、XML 加密等)，因此这种方法在使用时不可行SAML.

In comparison with the usual mobile authentication with IDPs (such as using OAuth 2 for Facebook/Google), SAML is more complicated. With OAuth 2.0 it's easy to extract the authorization token and intercept response by using a custom URL scheme, without need for a web deployed (SP) component. As SAML doesn't support flow similar to "implicit" in Oauth (for security reasons) and because processing of SAML response is much more complex (due to XML signatures, XML encryption, ...), this approach is not feasible when using SAML.