The situation right here is an iOS app operating within the background (display is off) downloads an ID Token from an Id supplier. The id token has an “expires at” area which is a unix timestamp one hour sooner or later. The ID token is verified utilizing the open supply AppAuth-iOS library right here.

The id token passes a number of checks so we all know it is legitimate till I attain this verify:

  NSTimeInterval expiresAtDifference = [idToken.expiresAt timeIntervalSinceNow];
      if (expiresAtDifference < 0) {
        NSError *invalidIDToken =
            [OIDErrorUtilities errorWithCode:OIDErrorCodeIDTokenFailedValidationError
                             underlyingError:nil
                                 description:@"ID Token expired"];
        dispatch_async(dispatch_get_main_queue(), ^{
          callback(nil, invalidIDToken);
        });
        return;
      }

This verify fails which suggests expiresAtDifference returned a unfavorable quantity when evaluating the system clock to the expire time which we all know is one hour sooner or later.

I additionally know the cellphone is in any other case utilizing community time and this verify passes throughout regular app utilization – the cellphone’s clock is not set unsuitable and is utilizing timezones and daylight financial savings correctly.

Is there any clarification for a way the Apple API timeIntervalSinceNow might be unsuitable when an app is backgrounded / cellphone asleep? Can it return 0 in any edge case like a dying battery or permission downside?

I can simply reproduce this error by disabling community time and altering the cellphone’s clock however this is not the case right here. I am actually baffeled by this one.