我碰到过不少类似的场景——两款应用对接同一个SecurityCheck适配器，单独登录都正常，但跨应用SSO就是不生效。结合MobileFirst 8.0的机制，大概率是几个关键配置细节没对齐，咱们一步步来排查：

1. 确认SecurityCheck的SSO核心配置 #

首先得确保你的SecurityCheck本身是支持SSO的：

• 检查自定义SecurityCheck的Java实现类，必须重写isSSOEnabled()方法并返回true：

  @Override
  protected boolean isSSOEnabled() {
      return true;
  }
  

• 另外，适配器的XML配置里，给这个SecurityCheck设置的realmName必须完全一致——两个应用要共享会话，必须指向同一个realm，哪怕大小写不同都会导致SSO失效。

2. 对齐应用端的SSO相关配置 #

两款应用的客户端配置必须严格统一：

• 打开mfpclient.properties文件，确认mfp.sessionCookieName完全相同。这个Cookie是存储SSO令牌的核心标识，名字不一样的话，应用之间根本识别不了彼此的会话。
• 同时mfp.serverUrl也必须完全一致，包括协议（http/https）、主机名、端口，不能一个用IP一个用域名，或者端口差了一位。

3. 验证应用的身份标识一致性（分平台） #

MobileFirst会根据应用的身份标识判断是否属于同一信任组，这一步很容易踩坑：

• Android平台：两款应用必须使用同一个签名密钥打包，并且都在MobileFirst控制台的应用配置里添加了该签名的SHA256哈希值。用不同密钥签名的应用，服务器会判定为不同主体，不会共享会话。
• iOS平台：两款应用必须拥有相同的Team ID，同时要确保在应用的Entitlements文件里配置了正确的keychain共享组（如果依赖keychain存储SSO令牌的话），控制台里的应用配置也要对应开启相关权限。

4. 排查服务器端的会话共享配置 #

如果前面的配置都没问题，就得看服务器端的会话管理了：

• 如果你用的是Liberty服务器，检查server.xml里的httpSession配置，确保cookieSameSite属性在HTTPS环境下设置为None，同时Cookie的域设置要覆盖两个应用的访问范围，让它们都能获取到SSO Cookie。
• 另外，确认服务器端没有给这个SecurityCheck设置针对单个应用的会话隔离规则，比如有没有在适配器配置里指定专属的会话存储。

5. 调试令牌共享逻辑 #

如果还是没解决，可以通过日志和客户端调试定位问题：

• 服务器端开启com.ibm.mfp.security的DEBUG日志，查看第二个应用启动时，服务器是否检测到已存在的SSO令牌。
• 客户端登录第一个应用后，调用MFPSecurity.sharedInstance().getSSOToken()获取令牌，然后在第二个应用启动时，检查是否能读取到同一个令牌（Android看SharedPreferences，iOS看Keychain，取决于你的令牌存储方式）。

大部分情况下，SSO失效都是因为realm名称不对、应用身份标识不匹配，或者Cookie配置不一致这几个点。先把这些基础配置对齐，应该就能解决问题。

内容的提问来源于stack exchange，提问作者farahm