AppAuth-iOS icon indicating copy to clipboard operation
AppAuth-iOS copied to clipboard

Facing the error - Issued at time is more than 600 seconds before or after the current time

Open rizwan95 opened this issue 4 years ago • 12 comments

Describe the bug When I try to authenticate against an authorization server, I am getting this error Error Domain=org.openid.appauth.general Code=-15 "Issued at time is more than 600 seconds before or after the current time" UserInfo={NSLocalizedDescription=Issued at time is more than 600 seconds before or after the current time}

The device's date and time are set properly. It was working properly for some time and now all of a sudden this error occurs

To Reproduce Steps to reproduce the behavior:

  1. Download the example project
  2. Provide your issuer, client ID, redirect URI, and client secret
  3. Try to login
  4. It logs in but in the call back, we get the error Error Domain=org.openid.appauth.general Code=-15 "Issued at time is more than 600 seconds before or after the current time" UserInfo={NSLocalizedDescription=Issued at time is more than 600 seconds before or after the current time}

Expected behavior The accesstoken should be available.

Smartphone (please complete the following information):

  • Device: iPhone 12 mini simulator
  • OS: macOS BigSur, M1
  • Xcode Version 12.5 beta

rizwan95 avatar Feb 13 '21 04:02 rizwan95

same issue here, did u solved this? only ipad got this error

fukemy avatar Feb 18 '21 09:02 fukemy

Sounds like a TimeZone issue

adozenlines avatar Feb 25 '21 23:02 adozenlines

The timezone of the server is set properly to UTC. Not sure what is wrong.

rizwan95 avatar Feb 26 '21 00:02 rizwan95

The code below is responsible for the message if the time between the server and the client is not in sync or skewed.

// OpenID Connect Core Section 3.1.3.7. rule #10
      // Validates that the issued at time is not more than +/- 10 minutes on the current time.
      NSTimeInterval issuedAtDifference = [idToken.issuedAt timeIntervalSinceNow];
      if (fabs(issuedAtDifference) > kOIDAuthorizationSessionIATMaxSkew) {
        NSString *message =
            [NSString stringWithFormat:@"Issued at time is more than %d seconds before or after "
                                        "the current time",
                                       kOIDAuthorizationSessionIATMaxSkew];

adozenlines avatar Mar 06 '21 16:03 adozenlines

Still, the server time and device time are correct, not sure how to solve it. @adozenlines

rizwan95 avatar Mar 06 '21 17:03 rizwan95

If the server is yours sync it to an internet clock/time service the clock on the server or the device is off or the server has bug in the generation of the timestamp for the issued at date & time.

adozenlines avatar Mar 06 '21 18:03 adozenlines

You can probably try using this locally via docker and see if the problem still happens with the AppAuth SDK: https://www.keycloak.org

adozenlines avatar Mar 06 '21 18:03 adozenlines

Okay I will try it, @adozenlines Thank you so much for your support!

rizwan95 avatar Mar 06 '21 18:03 rizwan95

Bump. This happens on iOS and Android since the check was added in 2021 because of a validation of the ID token timestamp per the spec:

  1. The iat Claim can be used to reject tokens that were issued too far away from the current time, limiting the amount of time that nonces need to be stored to prevent attacks. The acceptable range is Client specific.

However the code doesn't follow the spec correctly, it hard codes 10 mins in this repo:

static int const kOIDAuthorizationSessionIATMaxSkew = 600;

and here in android.

ID Token validation fails if a user sets their clock manually instead of automatic updates and it is exacerbated by daylight savings time changes. There are plenty of use cases where a user would set their clock manually such as not wanting to be on DST or wanting to be locked to different time zone when traveling.

We need to make this value client specific per the spec and configurable for those of us who want more flexibility in the time range - 61 mins for example.

bsautner avatar Dec 06 '23 16:12 bsautner

My case, the phones date and time was incorrect, after updating time to automaticaly. it worked

coucoseth avatar Dec 21 '23 08:12 coucoseth

_chat-3.txt

Brooksie18 avatar Dec 21 '23 21:12 Brooksie18

Thanks

Brooksie18 avatar Dec 21 '23 21:12 Brooksie18