AHi @Andrei Bogdanov sorry we had architectural meetings today. We will provide an answer tomorrow
AI am not sure if I get your use case right. We have a guide describing how a user can log in on an application this might help: https://docs.zitadel.com/docs/guides/integrate/login-users
AFirst, here is the tracking issue for client credentials if you're interested: https://github.com/zitadel/zitadel/issues/4211
If you want to authenticate the machine users, you currently have to use jwt profile grant or PAT. If you use PAT you can simply set the token in the Authorization header. The user needs an authorization on the resource server(s).
ZITADEL currently provides only opaque tokens for machine users. The resource server needs to introspect the token by sending it to zitadel: https://docs.zitadel.com/docs/apis/openidoauth/endpoints#introspection_endpoint
I'm not sure if you want to use basic auth to authenticate the user or introspect the token and check if the user has the required role.
If you want to authenticate the machine users, you currently have to use jwt profile grant or PAT. If you use PAT you can simply set the token in the Authorization header. The user needs an authorization on the resource server(s).
ZITADEL currently provides only opaque tokens for machine users. The resource server needs to introspect the token by sending it to zitadel: https://docs.zitadel.com/docs/apis/openidoauth/endpoints#introspection_endpoint
I'm not sure if you want to use basic auth to authenticate the user or introspect the token and check if the user has the required role.
GitHub
Service accounts can authenticate using JWT Profile. As alternative you can directly generate a PAT for authorization. While JWT Profile is very secure it's not always supported by 3rd part...
OpenID Connect 1.0 Discovery
Anot so far. We will track the state in this issue