simpleidserver
The issue of project initiation and token refreshing
Hello, I downloaded the project of the master main branch and found some problems
1、After the download start the project, "SimpleIdServer. IdServer. Startup", prompt can not find "SimpleIdServer. Scim. Domains" project, the need to manually add
2、I used this project: JsBffYarpSampleand encountered problems when trying to use the refresh token of your project：
This is my client configuration: I only changed the authentication address of his project
This is the configuration of the client I created in your project:
Other configurations are default.
When I start the JsBffYarpSample project without using the refresh token, I can log in normally and access the interface content. However, after I use the refresh token and the client logs in, the client will report an error, causing the request interface to be directly 401:
Excuse me, am I lacking any configuration somewhere?
3、I noticed that the offline_access created by default in your project belongs to the api resource in the Scope. Is it also okay for me to create an offline_access as the client resource and publish the refresh token normally? Is there any difference?
4、I noticed you "SimpleIdServer. IdServer. Startup" project "appsettings. Json" seems a lot more configuration items, I was confused when I try to configure the database, because I found configuration where there are many configuration database Such as: "DuendeMigrationOptions", "OpeniddictMigrationOptions", "KeyValueConfiguration", do you have about introduce configuration items in the "appsettings. Json" are what the point of the article, Which configurations are necessary and which are not?
Hello !
- This issue has already been fixed in the release/v6.0.3 branch. 🙂
- You encountered the exception "Error refreshing access token - Error = invalid client" because the authentication method used by the JsBffYarpSample differs from the one configured for the client. Could you please edit the Program.cs file and add the following statement, then try again?
builder.Services.Configure<UserTokenManagementOptions>(o =>
{
o.ClientCredentialStyle = Duende.IdentityModel.Client.ClientCredentialStyle.PostBody;
});
-
I'm not entirely sure what you're trying to achieve. While it's technically possible to remove or edit the offline_access scope, you should not do so. Like the openid scope, it is a standard scope and must not be modified. When using the authorization_code grant type, if the offline_access scope is included in the list of scopes, a refresh token will automatically be issued.
-
It's true that the appsettings.json file in the SimpleIdServer.IdServer.Startup project contains a lot of configuration data. This project is used by a .NET template, and it’s configured to enable all features provided by SimpleIdServer. You have the option to install either the full solution idserver, or a lighter one such as idserverempty or idserverui. You can find the complete list of templates here: 👉 https://simpleidserver.com/docs/installation/template
The following appsettings are not mandatory:
-
DuendeMigrationOptions: Used to migrate data from Duende to SimpleIdServer : https://simpleidserver.com/docs/idserver/migrations/duende
-
OpeniddictMigrationOptions: Used to migrate data from OpenIddict to SimpleIdServer: https://simpleidserver.com/docs/idserver/migrations/openiddict
-
KeyValueConfiguration: Used to store configuration options (like IdServerPasswordOptions) in a key-value store such as Redis.
Hello !
- This issue has already been fixed in the release/v6.0.3 branch. 🙂
- You encountered the exception "Error refreshing access token - Error = invalid client" because the authentication method used by the JsBffYarpSample differs from the one configured for the client. Could you please edit the Program.cs file and add the following statement, then try again?
builder.Services.Configure<UserTokenManagementOptions>(o => { o.ClientCredentialStyle = Duende.IdentityModel.Client.ClientCredentialStyle.PostBody; });
- I'm not entirely sure what you're trying to achieve. While it's technically possible to remove or edit the offline_access scope, you should not do so. Like the openid scope, it is a standard scope and must not be modified. When using the authorization_code grant type, if the offline_access scope is included in the list of scopes, a refresh token will automatically be issued.
- It's true that the appsettings.json file in the SimpleIdServer.IdServer.Startup project contains a lot of configuration data. This project is used by a .NET template, and it’s configured to enable all features provided by SimpleIdServer. You have the option to install either the full solution idserver, or a lighter one such as idserverempty or idserverui. You can find the complete list of templates here: 👉 https://simpleidserver.com/docs/installation/template
The following appsettings are not mandatory:
- DuendeMigrationOptions: Used to migrate data from Duende to SimpleIdServer : https://simpleidserver.com/docs/idserver/migrations/duende
- OpeniddictMigrationOptions: Used to migrate data from OpenIddict to SimpleIdServer: https://simpleidserver.com/docs/idserver/migrations/openiddict
- KeyValueConfiguration: Used to store configuration options (like IdServerPasswordOptions) in a key-value store such as Redis.
Thank you for your reply. The problem has been solved. 3、The reason why I ask this is that your scope is divided into two types: "API Resource" and "Identity Resource", your default "offline_access" is "API Resource". I was curious whether "offline_access" of different types would have an impact on refreshing the token. After my tests, it was found that It won't have an impact.
5、I noticed a previous discussion of yours: https://github.com/simpleidserver/SimpleIdServer/issues/835#issuecomment-2754717253 The default time for both token and cookie is 1800 seconds. Does this mean that to refresh the token, the expiration time of the cookie needs to be configured to be longer than that of the token? Is this necessary?
-
Offline scope: The offline_access scope can be defined as either an API resource or an identity resource. However, this has no impact on the generation of the refresh token. :) That said, it is preferable to define this scope as an API resource, as it is a standard scope and should never be used to return claims.
-
In general: The lifetime of the authentication cookie should be longer than that of the access token. Otherwise, you may encounter unexpected behavior on a website when it attempts to refresh the session using the session endpoint (typically via an iframe).
Hello, when I was learning about bff refresh tokens, I noticed this article https://docs.duendesoftware.com/bff/fundamentals/tokens/#reuse-of-refresh-tokens . Refresh tokens are divided into reusable refresh tokens and one-time tokens. Currently, when configuring refresh tokens on 5002, just check "refresh token" in the "Access request" on the client page. However, I didn't see the option to configure whether it's a one-time token or a repeated token. Currently, when this option is checked, is a one-time refresh token being used?
Good point!
At the moment, in SimpleIdServer, the refresh token can only be used once and cannot be reused. We will add support for multiple uses of the refresh token in release 6.0.4.
Kind regards, SID
Hello @qq1176914912 ,
This feature will be added in release 6.0.4. When editing a client's settings, you can now choose the refresh token usage mode: OneTimeOnly or ReUse.
According to various specifications and recommendations:
-
If the client is confidential (e.g., a backend API or a console application), the refresh token can be reused.
-
If the client is public (e.g., a SPA application), the refresh token must be used only once.
If you have any other suggestions or feature requests to help improve the product, please don’t hesitate to share them! 😊
KR, SID
Hello, sorry to disturb you. I'm currently using dex and adding your project to it for login. Both parties have enabled token refresh, and the token time of dex is set to 30 minutes. I noticed this issue of yours 835. You mentioned that if the cookie expires, the token refresh request will fail. It isn't me to want the cookies (UserCookieExpirationTimeInSeconds) is the right set up for a long time? Because as long as the cookie expires, the dex application to refresh the token will fail. Should it be set to one month or even one year? And TokenExpirationTimeInSeconds time is even less than 30 minutes of dex can also, the main is UserCookieExpirationTimeInSeconds configuration?
Really sorry now is like that, I in dex and configure the WeChat login, and log in your project, your project I configuration TokenExpirationTimeInSeconds as 3 s, UserCookieExpirationTimeInSeconds configuration, 432000000 (5) days, and then my client after login, web hanging don't do any operation, after a period of time, the customer is about to log back in, the time is uncertain, I don't know exactly where, in the question do you have any ideas?
My project version is still 0 b3877ae349d91881eecc66180e75aeb17925c47 Commits on Apr 8, 2025 I don't know if there is a problem with this version
Is this the log I checked the problem here? Should it be solved after updating your project? log.txt
Is this the log I checked the problem here? Should it be solved after updating your project? log.txt
I understand the problem now. The version I'm using is that your refresh token does not support reuse, while I configured the dex to be reusable, which led to this error