Current Limitation
Assertion, access token, ID token, and userinfo attributes are derived exclusively from the application's allowed user types, in both the Console and the backend. Current authentication logic already works and agents can get a valid token from authenticating via login flows. The token includes any attributes that are common in both agent schema and user types but misses any agent specific attribute. But there is no way to select an attribute declared in an agent schema, so agent-specific attributes cannot be released in any token even though agents can already sign in to applications.
The limitation is entirely at configuration time. Runtime issuance is name-driven rather than schema-driven, and already handles agent subjects correctly. The attributes would flow if they could be configured.
Suggested Improvement
Resolve valid token attributes per entity category instead of assuming users, and give agent attributes their own configuration surface.
In the backend, generalize resolving and validating token attributes in backend/internal/inboundclient/service.go to resolve attributes from allowed agent type schemas as well as allowed user type schemas, validating each audience's list against its matching category.
In the console, design an option to configure agent attributes in the access token.
Current Limitation
Assertion, access token, ID token, and userinfo attributes are derived exclusively from the application's allowed user types, in both the Console and the backend. Current authentication logic already works and agents can get a valid token from authenticating via login flows. The token includes any attributes that are common in both agent schema and user types but misses any agent specific attribute. But there is no way to select an attribute declared in an agent schema, so agent-specific attributes cannot be released in any token even though agents can already sign in to applications.
The limitation is entirely at configuration time. Runtime issuance is name-driven rather than schema-driven, and already handles agent subjects correctly. The attributes would flow if they could be configured.
Suggested Improvement
Resolve valid token attributes per entity category instead of assuming users, and give agent attributes their own configuration surface.
In the backend, generalize resolving and validating token attributes in
backend/internal/inboundclient/service.goto resolve attributes from allowed agent type schemas as well as allowed user type schemas, validating each audience's list against its matching category.In the console, design an option to configure agent attributes in the access token.