Authority data is persisted across different SDK instances
Company PR: https://github.com/AzureAD/microsoft-authentication-library-for-android/pull/2151
Investigation Summary:
- The first SDK instance: since there is no authorityIsKnownFromConfiguration, Authority class will return CIAMAuthority(authorityUrl) which has no client id inside. However, under NativeAuthPublicClientApplicationConfiguration.validateConfiguration, the CIAMAuthority is converted into NativeAuthCIAMAuthority with client id attached.
if (defaultAuthority is CIAMAuthority) {
val nativeAuthAuthority = NativeAuthCIAMAuthority(
authorityUrl = defaultAuthority.authorityUri.toString(),
clientId = clientId
)
authorities.clear()
authorities.add(nativeAuthAuthority)
- The second SDK instance: there is an authorityIsKnownFromConfiguration because authority url is the same. Authority class used the previous cliend id that wrapped inside the authority instance to generate a new NativeAuthCIAMAuthority. Thus the client id inside this one authority is conflicted with the current right client id, which cause the failure of tests.
authority = new NativeAuthCIAMAuthority(authorityUrl, ((NativeAuthCIAMAuthority) configuredAuthority).getClientId());
The target of this PR is dev branch
@Yuki-YuXin can you explain why this fixes the issue (i.e. the issue of having a singleton to manage "known authorities" which effectively shares data across multiple SDK instances)? This PR seems to fix the issue in a different place; I'm not sure that's correct.
@SammyO When I was trying to understand the problem, I personally think singleton authority may not be the reason. The root cause is NativeAuthCIAMAuthority wraps a client id parameters and store it for the second time usage. Indeed, the code only uses the authority url to search for the known authority in the second time, which is the first time NativeAuthCIAMAuthority (authorityUrl, legacy client id of the first time). The conflicts between the client id and the one inside NativeAuthCIAMAuthority fail those tests.