bug: Can not Exchange token by Refresh Token after time

[gtjadsonsantos]

Describe the bug

This issue This issue #7840 has been closed. I went to test the fix in the new version v1.34.0 where the change was applied, but the same behavior occurs. I really need this resolved.

Two weeks have passed and the problem still persists. I set the maximum time you changed @wangsijie, and even so, after two weeks the same behavior happened again; it reported that the refresh token was not found.

{
  "key": "ExchangeTokenBy.RefreshToken",
  "result": "Error",
  "error": "{\"stack\":\"InvalidGrant: invalid_grant\\n    at file:///etc/logto/packages/core/build/main-TKJPWNIA.js:3519:11\\n    at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\\n    at async callTokenHandler (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/actions/token.js:70:7)\\n    at async allowedGrantTypeCheck (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/actions/token.js:53:7)\\n    at async supportedGrantTypeCheck (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/actions/token.js:45:7)\\n    at async stripGrantIrrelevantParams (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/actions/token.js:33:7)\\n    at async auth (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/token_auth.js:266:9)\\n    at async loadClient (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/token_auth.js:161:9)\\n    at async setWWWAuthenticateHeader (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/token_auth.js:52:11)\\n    at async selectiveBody (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/selective_body.js:49:5)\\n    at async noCache (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/no_cache.js:3:3)\\n    at async cors (/etc/logto/node_modules/.pnpm/@koa+cors@5.0.0/node_modules/@koa/cors/index.js:106:16)\\n    at async errorHandler (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/error_handler.js:26:7)\\n    at async ensureSessionSave (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/helpers/initialize_app.js:52:7)\\n    at async contextEnsureOidc (file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/shared/context_ensure_oidc.js:4:5)\\n    at async file:///etc/logto/node_modules/.pnpm/oidc-provider@https+++codeload.github.com+logto-io+node-oidc-provider+tar.gz+aa47a2b000d08e28c1d212aac1899eddd13009e9/node_modules/oidc-provider/lib/helpers/initialize_app.js:225:5\",\"message\":\"invalid_grant\",\"allow_redirect\":true,\"name\":\"InvalidGrant\",\"error\":\"invalid_grant\",\"status\":400,\"statusCode\":400,\"expose\":true,\"error_description\":\"grant request is invalid\",\"error_detail\":\"refresh token not found\"}",
  "ip": "54.239.98.66",
  "userAgent": "Apache-HttpClient/UNAVAILABLE (Java/1.8.0_472)",
  "applicationId": "ly3v9b63x256flw76jv7g",
  "params": {
    "client_id": "ly3v9b63x256flw76jv7g",
    "grant_type": "refresh_token",
    "refresh_token": "zco-tnJmTFC0Dqy4O8eHr8DmeNoIW7n28rz9WpYFFrg"
  },
  "tokenTypes": [],
  "applicationSecret": {
    "name": "Default"
  }
}

My version logto is v1.34.0

My application Alexa

Expected behavior

May the token exchange continue to function

How to reproduce?

is to create an application and the application must be trying to use the refresh token over a week and a half, the error will probably appear the same.

Environment

Self-hosted (Docker image)

Screenshots

No response

[wangsijie]

Hi @gtjadsonsantos, I'll do a local test

[wangsijie]

Hi @gtjadsonsantos, thanks for reporting this.

The fix in v1.34.0 only affects newly created grants and refresh tokens. If your Alexa skill was linked before the upgrade, the existing grant record in the database still has the old 14-day TTL.

Could you confirm whether this refresh token was created after you upgraded to v1.34.0? If it was created before the upgrade, you would need to re-link your Alexa skill to get a new refresh token with the extended TTL.

[gtjadsonsantos]

So, here are some records I've compiled from my database.

This record is the refresh that was saved in my database, but the expires_at column indicates a long expiration date.

But that didn't happen; it expired in two weeks.

Regarding your question, I think I re-linked the account with the skill and then upgraded to the new version 1.34.0. However, I didn't check if the expiration date in the database was actually high.

[gtjadsonsantos]

I really want to help you resolve this; whatever feedback you need, I'm available to test and report back.

[gtjadsonsantos]

@wangsijie It happened again, with another Alexa skill user, and I remember this one linking it using the new version v1.34.0.

[wangsijie]

After further investigation, I found the root cause.

When a refresh token is issued without the offline_access scope in the authorization request, it will be bound to the user's session. The session TTL is 14 days. After the session expires, even if the refresh token itself hasn't expired (e.g., set to 180 days), the token lookup will fail because the associated session no longer exists.

Could you check if your Alexa skill's authorization request includes the offline_access scope?

You can verify this by checking the payload column in the oidc_model_instances table for your refresh token record:

SELECT payload FROM oidc_model_instances 
WHERE model_name = 'RefreshToken' 
AND id = '<your_refresh_token_id>';

Look for the scope field in the payload - if it doesn't contain offline_access, that's the issue.

Solution: Make sure your Alexa skill requests the offline_access scope during authorization. This will prevent the refresh token from being bound to the session, allowing it to remain valid for the full configured TTL (e.g., 180 days).

[gtjadsonsantos]

The Alexa skill isn't actually adding that offline_access scope, even though I've added it there.

Here is the payload for my refresh token.

{"exp": 1782920361, "gty": "authorization_code", "iat": 1767368361, "jti": "z9K7ebeU_JUzWUItUXfUlIaXlyDHglzTdgvcO8m4fdz", "iiat": 1767368361, "kind": "RefreshToken", "scope": "openid profile custom_data urn:logto:scope:organization_roles identities phone roles email urn:logto:scope:organizations address", "grantId": "fyODdrKTToH8BjF-qXtJlgxmkggxCWv0pBlBMOXiQEm", "authTime": 1767368354, "clientId": "ly3v9b63x256flw76jv7g", "accountId": "jcdqaft7nul0", "rotations": 0, "sessionUid": "vz5NwGWc3V2_hcTK49YQh", "expiresWithSession": true}

I'll try to report this to them; it doesn't make sense for them to ignore this scope.

But they're very slow to respond. One question: is there anything we can do on our end to get around this?

[wangsijie]

Here are two options:

1. Quick workaround (if you're self-hosting):

Increase the session TTL in the source code:

File: packages/core/src/oidc/init.ts, line 365:

// Change from 14 days to 180 days
Session: 15_552_000 /* 180 days in seconds */,

Then rebuild and redeploy.

2. Wait for a new feature:

Maybe we can add an alwaysIncludeOfflineAccessScope option for applications, which would force-inject the offline_access scope on the server side even when the client doesn't request it.

[gtjadsonsantos]

The second option seems to be the best