I got this solved with this document and some guesses: https://abp.io/docs/latest/guides/synchronous-interservice-communication Point 1: set UseCurrentAccessToken to false
appsettings: "RemoteServices": { "Iot": { "BaseUrl": "https://localhost:44351/", "UseCurrentAccessToken": "false" --> I was missing this. } }, Point 2: define client "IdentityClients": { "Default": { "GrantType": "client_credentials", "ClientId": "IotIntegration", "ClientSecret": "IotIntegration__something", "Authority": "https://localhost:44321", "Scope": "IotCombinedIntegrationAppService" } },
Point 3: Create client and scope for the openIdDict also with proper resource (missing from instructions) that shall used. --> I was missing this.
Point 4: when querying token the scope "IotCombinedIntegrationAppService" needs to be included
[berkansasmaz] said: Hi Tapmui,
You don’t need to apply authorization to Integration Services, because these endpoints are not exposed externally. If a user request is already validated by [Authorize] in your Application Service or Controller, there’s no need to check authorization again for internal calls. Integration Services are only used internally between modules or services, and users cannot directly send requests to these endpoints if it's not intentionally exposed to the outside in your deployment configuration.
See more:
- https://github.com/abpframework/abp/issues/12470
- https://abp.io/docs/latest/framework/api-development/integration-services#exposing-integration-services
Hi BerkansasMaz, thank you for the response. I have to expose the API, due we have modular monolith implementation (or even kind of microservice though not following microservice patterns but logical modules)
Related issue: I also tried to use the dynamic proxy directly via the client API that already exists there. (I would not need to use integration service at all). But I had the same issue with authorization (401). Can you please advice on this. As per my understanding (from documentation) dynamic or static proxy client should use automatically existing token during the call ?
Best regards Tapio
[AI-Bot] said:
When you access an ABP Integration Service endpoint from another backend service, the request must include a valid authentication token with the required permissions. If the endpoint is protected by
[Authorize]or a permission attribute, and the calling service does not forward the user's access token or does not use a valid service-to-service token with the necessary claims, you will get a 401 Unauthorized error.Integration Services are not exposed by default and typically do not require authorization, but if you add
[Authorize]or permission attributes, you must ensure the caller is authenticated and authorized. When you call the endpoint directly (e.g., via Postman), you provide a valid token, so it works. When called from another backend service, unless you explicitly forward the user's token or use a client credentials flow, the call is unauthenticated.Solution:
Forward the User's Access Token:
- When backend service A calls the integration service, ensure it forwards the current user's access token in the Authorization header. This way, the integration service can perform authorization checks based on the user's permissions.
- In ABP, you can use the
IAccessTokenProvideror similar mechanism to retrieve and forward the token.Use Client Credentials (Service-to-Service):
- If the call is not on behalf of a user, configure IdentityServer to allow client credentials for service A, and assign the required permissions to the client. The integration service will then authorize based on the client identity.
Check Integration Service Exposure:
- Make sure you have set
AbpAspNetCoreMvcOptions.ExposeIntegrationServices = truein your module configuration to expose integration services.Security Note:
- If you remove
[Authorize], the endpoint is open to anyone, which is a security risk. Always require authentication and proper permissions.Example: Forwarding the Token
// In backend service A, when calling the integration service: var client = _httpClientFactory.CreateClient("IntegrationService"); client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Bearer", userAccessToken); // Forward user's tokenReferences:
This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.
Thanks for the fast initial response. Comments to it below. to point 1;2; Based on this document I understood that abp.io is doing the addtion of access token automatically: https://abp.io/docs/latest/framework/api-development/dynamic-csharp-clients --> Authenticates the HTTP Client by adding access token to the HTTP header. to point 3; yes already done. -I have also tried to use the dynamic http API directly without integrationservice model; same result (unauthorized). **To point 4: **that is clear as I already said. I'm a bit worried that this is not highlighed in the abp.io documentation clearly.
Example usage of integration/dynamic proxy:
`
GetIotCombinedDatasInput combinedDatasInput = new GetIotCombinedDatasInput
{
MaxResultCount = 10,
SkipCount = 0,
// DeviceTime < 2025-09-29 12:51:35.394
DeviceTimeMax = DateTime.Parse("2025-09-29T12:51:35.394", null, DateTimeStyles.AdjustToUniversal)
};
try
{
var ressu = await _iotCombinedDatasAppService.GetListAsync(combinedDatasInput);
} catch(Exception e)
{
_logger.LogWarning("not working...", e.Message);
throw;
}
`
Hi,
This is a problem, it seems we haven't updated the download file. I will ask the platform team.
What's your email, I can share it via email for now.
Please send it to this address: tapio.muikku@elisaindustriq.com
Ho Liangshiwei, I downloaded the source code; not on net9 level. Result is as follows: global,json: { "sdk": { "version": "8.0.401", "rollForward": "latestFeature" } } common.props: <Project> <PropertyGroup> <LangVersion>latest</LangVersion> <Version>1.0.0</Version> <NoWarn>$(NoWarn);CS1591</NoWarn> <AbpVersion>8.3.1</AbpVersion> <BlazoriseVersion>1.5.2</BlazoriseVersion> </PropertyGroup> </Project>
..domain.csproj; <Project Sdk="Microsoft.NET.Sdk">
<Import Project="....\common.props" />
<PropertyGroup> <TargetFramework>net8.0</TargetFramework> <RootNamespace>Volo.EasyCrm</RootNamespace> </PropertyGroup> ..
Thanks again.
If we used lepton material theme in the application. Does it support ie. material themes directly ?
sorry, didn't get this question!
With this question I meant if I change ie. a primary color from lepton theme; or even changing the theme to dark one; is changes also happening with material UI based components ?
Hi Alper. Thank you for the quick response.
normally you should be using Suite.
Any reasons on this, why not to change templates ?
but you need to change the templates
Yes, I was already analysing how to change of templates. Template data seem to live in Volo.Abp.Commercial.SuiteTemplates.dll nuget. So when I changed it, it is only in my own PC, right ? Or was it changed on a solution level ? I'm thinking the case where several persons generate components on the solution; how we should manage this situation.
Another related question is about theme colors: if we used lepton material theme in the application. Does it support ie. material themes directly ?