bug: logto/client getAccessToken with a resource does not include the scopes in the token

[maddijoyce]

Describe the bug

Using logto/node, I'm authenticating my user then attempting to get a JWT access token, so I call

const token = await client.getAccessToken(resourceUrl);

The token is successfully generated and returned, however it does not have any scopes.

Expected behavior

I believe the token should have the scopes from the options when the client is initialised, but looking at the source -

js/packages/client/src/client.ts

Line 449 in c540dd6

const { accessToken, refreshToken, idToken, scope, expiresIn } = await fetchTokenByRefreshToken(

- it does not include scopes in this call.

I'm happy to add a PR for this, just wanted to check this was in fact a bug.

How to reproduce?

• Create a new Client from @logto/node
• Authenticate the client
• Call getAccessToken with a resource.

Environment

Self-hosted (Docker image)

Screenshots

No response

[wangsijie]

Hi, you need to add the resource and scopes when initializing the Logto client, then use that client inside this function.

[maddijoyce]

Hey @wangsijie, I'm including the scopes when I initialize the client, then calling client.getAccessToken(resourceUrl), which in turn calls the private method getAccessTokenByRefreshToken.
However, this code here -

js/packages/client/src/client.ts

Lines 449 to 458 in c540dd6

	const { accessToken, refreshToken, idToken, scope, expiresIn } = await fetchTokenByRefreshToken(
	{
	clientId,
	tokenEndpoint,
	refreshToken: currentRefreshToken,
	resource,
	organizationId,
	},
	this.adapter.requester
	);

- does not pass the scopes to the fetchTokenByRefreshToken function. I just wanted to check this wasn't intentional for some reason before I raise a PR.

[wangsijie]

@maddijoyce Yeah, that’s not intentional. It’s okay to pass an extra scope param to fetchTokenByRefreshToken, the backend API handles it.

[250king]

Well, I have same proble about it: why it don't give reources to fetchTokenByAuthorizationCode?

https://docs.logto.io/zh-CN/authorization/global-api-resources#authorization-code-or-refresh-token-flow

https://docs.logto.io/zh-CN/authorization/role-based-access-control#default-api-resource-behavior

It leds that I get a opaque token and it isn't included the scope I have give.

[wangsijie]

I took a closer look at the backend token endpoint implementation. When the scope parameter is not provided in the refresh token request, the server falls back to refreshToken.scopes, which already contains all scopes from the original authorization (both OIDC and resource scopes). The final access token scopes are determined by:

grant.getResourceScopeFiltered(resource, refreshToken.scopes ∩ resourceServer.scopes)

So the absence of scope in the SDK request should not cause missing scopes in the token.

If the returned token has no scopes, please check:

1. The API resource has scopes defined in the Logto Console
2. The user has a role assigned with those scopes for that resource
3. The scopes in the client config match what's configured on the resource

[wangsijie]

@250king The behavior you're seeing is expected. During the initial authorization code exchange, the SDK does not pass resource to the token endpoint, so the server returns a default OIDC access token (opaque). This is by design because multiple resources may be configured, and the auth code exchange only accepts a single resource.

To get a JWT access token for a specific resource, call getAccessToken after sign in:

const token = await client.getAccessToken('https://your-api-resource');

This triggers a refresh token grant with the resource parameter, and the server will return a JWT with the appropriate scopes.

[wangsijie]

Closing this as the current behavior is expected. Feel free to reopen if you still have questions.