Describe the bug

When an OAuth2/OIDC server returns expires_at as a string that cannot be parsed as an integer, the OAuth2Token initialization fails with a ValueError. This prevents token creation even when expires_in is available and could be used to calculate the expiration time.

Since expires_at is not defined in the OAuth2 RFC and some OIDC servers may return it in non-standard formats, the library should gracefully handle unparseable values and fall back to expires_in.

Steps to reproduce

from authlib.oauth2.rfc6749.wrappers import OAuth2Token

# Simulate a token response where expires_at is a non-integer string
token_params = {
    "access_token": "sample_token",
    "expires_at": "2025-10-10T12:00:00Z",  # Some servers return datetime string
    "expires_in": 3600,
    "token_type": "Bearer"
}

# This will raise ValueError 
token = OAuth2Token(token_params)

The will fail with a ValueError when it tries to convert expires_at to an integer:

Traceback (most recent call last):
  File "authlib/oauth2/rfc6749/wrappers.py", line 9, in __init__
    params["expires_at"] = int(params["expires_at"])
ValueError: invalid literal for int() with base 10: '<non-integer-string-value>'

Expected behavior

If expires_at cannot be parsed as an integer, we cannot be expected to know how to parse it because it is not defined in the RFC. The class should prioritize the RFC-compliant expires_in over expires_at if both are provided and expires_at is unparsable.

Environment:

• Python Version: 3.13
• Authlib Version: eb37124