use of com.microsoft.identity.common.internal.telemetry.events.CacheStartEvent in project microsoft-authentication-library-common-for-android by AzureAD.
the class MsalOAuth2TokenCache method load.
@Override
public ICacheRecord load(@NonNull final String clientId, @Nullable final String target, @NonNull final AccountRecord account, @NonNull final AbstractAuthenticationScheme authScheme) {
Telemetry.emit(new CacheStartEvent());
final boolean isMultiResourceCapable = MicrosoftAccount.AUTHORITY_TYPE_V1_V2.equals(account.getAuthorityType());
// 'Preloading' our credentials to avoid repeated expensive cache hits
final List<Credential> allCredentials = mAccountCredentialCache.getCredentials();
// Load the AccessTokens
final List<Credential> accessTokens = mAccountCredentialCache.getCredentialsFilteredBy(account.getHomeAccountId(), account.getEnvironment(), getAccessTokenCredentialTypeForAuthenticationScheme(authScheme), clientId, account.getRealm(), target, authScheme.getName(), allCredentials);
// Load the RefreshTokens
List<Credential> refreshTokens = mAccountCredentialCache.getCredentialsFilteredBy(account.getHomeAccountId(), account.getEnvironment(), CredentialType.RefreshToken, clientId, isMultiResourceCapable ? // wildcard (*)
null : account.getRealm(), isMultiResourceCapable ? // wildcard (*)
null : target, // not applicable
null, allCredentials);
if (refreshTokens.isEmpty()) {
// If we didn't find an RT in the cache, this could be a "TSL-seed" or "dual-client stack"
// scenario
//
// Defining these terms:
// TSL-seed: another 1P TSL integrated app has put a token into our cache so we can
// pick it up
//
// Dual-Client stack: two FoCI-enabled app registrations are sharing a single binary
// and accordingly, can share RTs.
// Examples for this might be TFL/TFW - which uses multiple client ids to enable
// different scenarios depending on enterprise vs. consumer usage
// Unlike the broker, where we check if an app is FoCI prior to making a network call
// with an arbitrary FoCI RT we find in the cache, if we're in standalone mode and find
// a FoCI RT in the cache, the current app must also be FoCI (!!!)
//
// Making the assumption that the current client id can use any FoCI RT we find in the
// cache is strictly contingent that app developers NOT mix FoCI/non-FoCI registrations
// into same binary. If you do this, you'll get confusing errors that the RT used doesn't
// match the client app registration. This assumption means we don't need to implement
// "FoCI probing" and/or track FoCI app meta
final Credential fallbackFrt = getFamilyRefreshTokenForAccount(account);
if (null != fallbackFrt) {
refreshTokens = new ArrayList<>();
refreshTokens.add(fallbackFrt);
}
}
// Load the IdTokens
final List<Credential> idTokens = mAccountCredentialCache.getCredentialsFilteredBy(account.getHomeAccountId(), account.getEnvironment(), IdToken, clientId, account.getRealm(), // wildcard (*),
null, // not applicable
null, allCredentials);
// Load the v1 IdTokens
final List<Credential> v1IdTokens = mAccountCredentialCache.getCredentialsFilteredBy(account.getHomeAccountId(), account.getEnvironment(), CredentialType.V1IdToken, clientId, account.getRealm(), // wildcard (*)
null, // not applicable
null, allCredentials);
final CacheRecord.CacheRecordBuilder result = CacheRecord.builder();
result.account(account);
result.accessToken(accessTokens.isEmpty() ? null : (AccessTokenRecord) accessTokens.get(0));
result.refreshToken(refreshTokens.isEmpty() ? null : (RefreshTokenRecord) refreshTokens.get(0));
result.idToken(idTokens.isEmpty() ? null : (IdTokenRecord) idTokens.get(0));
result.v1IdToken(v1IdTokens.isEmpty() ? null : (IdTokenRecord) v1IdTokens.get(0));
Telemetry.emit(new CacheEndEvent().putCacheRecordStatus(result.build()));
return result.build();
}
Aggregations