Eventually, modules will have running end applications eventually, just as microservices are running (HttpApi.Host projects) themselves.
So, you will need to register the running application (client) to the authority (identityserver) with the related permissions so that you can make client_credential (server-to-server) calls automatically in your background worker application.
You can check guide about communication between microservices, it can give some information about it.
Thank you, I have checked and reproduced the problem.
Fixed the related issue, it should be available in the next release.
I am sorry, I misspell it, I tried on 4.4.3, not 4.3.3.
Can you share the project that you reproduced to support@abp.io?
Redirect_uri's are declared when client is created. See https://support.abp.io/QA/Questions/1951/500-Internal-Server-Error-Invalid-redirecturi#answer-99adb092-2a26-5dbb-6bac-39ff6bc7b817
To clarify, do you want to deploy all your applications (Http.Api.Host, Web and IdentityServer) to same domain with sub folders? Web is running on: mydomain Http.Api.Host on: mydomain.com/api IdentityServer on: mydomain.com/account
If so, you will need to write Rewrite rule in load balancer (nginx i suppose) to redirect to /account
You can check deployment configurations docs. Also official identityserver4 deployment docs.
If you have already deployed identityserver, you can also share its link.
It is not possible to understand the error without checking the logs.
Please reproduce the error and then check the logs (Log/logs.txt or console output) and search for [ERR].
No, you can not use client_credentials in angular, it is server to server (backend to backend) flow.
Suggested authentication flow for SPA is Authorization Code with PKCE; you click to login and get redirected to authentication (identityserver) domain to login, then you login in that domain.
Other way is Resource Owner Password Credentials; where you host the login page in your SPA application and let users enter username/password to your frontend application instead of redirecting to identityserver.
When you use password_grant, you use the user for authenticating to system and user has declared permissions for it (from roles or user permissions).
When you use client_credentials, you use secure and non-user an other system (back-end application forexample) for authenticating to system. So, we need to grant permissions to the non-user system since it can not have roles that has permissions.
If you are using postman to test and you need to grant a specific permission for your system; an easy way is to generate a guid and add it into dabase PermissionGrants table:
Where ProviderName is C (for ClientCredential) and ProviderKey is the name of your system (Client) saved in your IdentityServer Clients table