Correct time from token

[vbjay]

See https://openid.net/specs/openid-connect-core-1_0.html#IDToken

Details

• exp
  REQUIRED. Expiration time on or after which the ID Token MUST NOT be accepted for processing. The processing of this parameter requires that the current date/time MUST be before the expiration date/time listed in the value. Implementers MAY provide for some small leeway, usually no more than a few minutes, to account for clock skew. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular.

• auth_time
  Time when the End-User authentication occurred. Its value is a JSON number representing the number of seconds from 1970-01-01T0:0:0Z as measured in UTC until the date/time. When a max_age request is made or when auth_time is requested as an Essential Claim, then this Claim is REQUIRED; otherwise, its inclusion is OPTIONAL. (The auth_time Claim semantically corresponds to the OpenID 2.0 PAPE [OpenID.PAPE] auth_time response parameter.)

Issues

• Adding current time and the value of the expires in will result in an expires in that will be way after the actual expires in value.
• Authentication time isn't when you got the token. It is when the user authenticated. This is not currently exposed in https://github.com/IdentityModel/IdentityModel/blob/main/src/Client/Messages/TokenResponse.cs but should be.

[leastprivilege]

Adding current time and the value of the expires in will result in an expires in that will be way after the actual expires in value.

not following here

Authentication time isn't when you got the token. It is when the user authenticated.

I agree. What do you propose (besides adding it to TokenResponse)?

[vbjay]

Adding current time and the value of the expires in will result in an expires in that will be way after the actual expires in value.

not following here

Sample results of a token

{
    "exp": 1608360160,
    "auth_time": 1607898926
}

Adding 1608360160 to Now vs 1970-01-01T0:0:0Z is a huge difference.

Authentication time isn't when you got the token. It is when the user authenticated.

I agree. What do you propose (besides adding it to TokenResponse)?

• Using AuthTime from token response and if that is 0 then fall back to DatetimeOffset.Now for AuthTime.
  • Optionally adding a AuthTimeType enum and value to LoginResult. This will let them know if it did fall back or not.
  • TokenAuthTime, TokenRetrievalTime
• Fixing ExpiresIn to do the correct time calc from 1970-01-01T0:0:0Z.

[vbjay]

I could also instead of falling back, make AuthenticationTime a nullable property. If the value is 0 coming from TokenReponse then make return null.

[vbjay]

var loginResult = new LoginResult
            {
                User = user,
                AccessToken = result.TokenResponse.AccessToken,
                RefreshToken = result.TokenResponse.RefreshToken,
                AccessTokenExpiration = new DateTimeOffset(TOKEN_START_TIME, TimeSpan.Zero).AddSeconds(result.TokenResponse.ExpiresIn), // see https://openid.net/specs/openid-connect-core-1_0.html 
                IdentityToken = result.TokenResponse.IdentityToken,
                AuthenticationTime = new DateTimeOffset(TOKEN_START_TIME, TimeSpan.Zero).AddSeconds(result.TokenResponse.AuthTime ?? 0),
                TokenResponse = result.TokenResponse // In some cases there is additional custom response data that clients need access to
            };

Rough idea. Depends on if you add AuthTime to response. I can then check for is the datetimeoffset = to TokenStartTime and if so return datetimeoffset.now. Can also just return null datetimeoffset. Depends on which way you want to go.

[vbjay]

Ok. Did some more digging. The expires in is fine. It is just the Authentication time.

{
  "nbf": 1608402513,
  "exp": 1608402813,
  "iss": "https://localhost:44310",
  "aud": "***",
  "nonce": "ftrQE63lg_1J6LcC44Upow",
  "iat": 1608402513,
  "at_hash": "2O-2ED8IhwuMBBG9WeiB4A",
  "s_hash": "OikTlgBrh6rXOuXo6Uqujw",
  "sid": "FEA159E61F3DA0BA8C41D5AD394468E9",
  "sub": "994bad30-fcd6-4efb-a1f9-57440d2edee8",
  "auth_time": 1607898926,
  "idp": "local",
  "name": "***",
  "website": "https://123.com",
  "RandomID": "784a8bab-1788-4fc2-ba49-2272e8119980",
  "preferred_username": "***",
  "email": "Not telling",
  "email_verified": true,
  "amr": [
    "mfa"
  ]
}

auth_time is 1607898926 which is 12/13/2020 10:35:26 PM +00:00. However the client at the moment is giving me the following values. I would expect the authentication time to reflect auth_time.
Sign In occured: 12/19/2020 1:56:31 PM -05:00
Authentication Time: 12/19/2020 1:56:31 PM

So I will fix it so the authentication time is right in a pull request soon.

[vbjay]

@leastprivilege Quick question. The expires in uses now. Shouldn't it be iat value + expires_in? I'll try it and we we can remove it if it isn't right.

[leastprivilege]

The expires_in is about the access token. The client cannot look inside the access token - so all the client has is the expires_in parameter on the oauth response.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue.