Feature request: Service account

[pluservice]

Is your feature request related to a problem? Please describe.
Client creation rest api does not allow to associate a service account to a client specifying claims , subject , scopes of the service account..

Describe the solution you'd like
It could be very useful to be able to associate a service account to the client with subject claims and scopes to be used with "Client Credential flow"

Additional context
The following solutions allow this
https://developers.google.com/identity/protocols/OAuth2ServiceAccount
https://www.keycloak.org/docs/latest/server_admin/index.html#_service_accounts
https://kubernetes.io/docs/reference/access-authn-authz/authentication/

[aeneasr]

I still don't get it, the Keycloak documentation says veryl clearly:

Each OIDC client has a built-in service account which allows it to obtain an access token. This is covered in the OAuth 2.0 specifiation under Client Credentials Grant. To use this feature you must set the Access Type of your client to confidential. When you do this, the Service Accounts Enabled switch will appear. You need to turn on this switch. Also make sure that you have configured your client credentials.

    POST /auth/realms/demo/protocol/openid-connect/token
    Authorization: Basic cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=
    Content-Type: application/x-www-form-urlencoded

    grant_type=client_credentials

This is 100% supported in ORY Hydra. Please provide a flow example or the appropriate IETF RFC. We're also generally not implementing non-standardized flows or specifications which are in draft status.

[pluservice]

This feature is related to the "Client Credential flow" , it is not a new flow.
It's about the subject returned inside the access token.

In keycloak the access token returned after a "Client Credential Flow" login contains the subject of a built-in service account and its claims and scopes can be customized at will.

Google allows creation of custom service accounts.

[aeneasr]

Yeah, as I've said already, this is possible today with ORY Hydra. Just create an OAuth2 Client with a client ID of your choosing (that will be the subject) and allow that OAuth2 Client to request the permissions/OAuth2 Scope you want it to be able to.

[pluservice]

What is missing is the possibility to set claims.
That is to set the properties of service accounts which are used only in the context
of a "Client Credential flow".

[aeneasr]

What do you mean with claims? Please explain and give an example.

[pluservice]

I mean public or private claims ie name, email
registered public claims https://www.iana.org/assignments/jwt/jwt.xhtml
OIDC
https://openid.net/specs/openid-connect-core-1_0.html#IANA

[aeneasr]

You are mixing concepts that do not match. An OpenID Connect ID Token (what you linked with oidc core) is not an ID Token, and not the flow Keycloak implements. A client credentials flow is never able to request an ID Token. Please read the section you linked in the Keycloak document with attention.

JWTs are not only a method of transporting information in a stateless manner, it has nothing to do with OAuth2 itself.

Google implements a proprietary (they invented it, and it is not standardised afaik) flow which allows you to work with their platform in their (proprietary) way. This is not something that will be implemented in this project.

[pluservice]

Access token may contain some claims , I put links to explain what claims are, I did not mean to
put identity claims on the access token,
keycloak allow to set custom claims in the access token response for a "Client Credential Flow"
I find it a useful thing ,

According to oAuth
The token may denote an identifier used to retrieve the authorization
information or may self-contain the authorization information in a
verifiable manner (i.e., a token string consisting of some data and a
signature).

[pluservice]

By the way, given the access token obtained with the "Client Credential Flow" ,
Keycloak OAuth 2.0 UserInfo Endpoint allows to retrieve user information (Claims
about the authenticated End-User) that in this case is the service account , the claims
returned by the userinfo invocation are the ones supplied during client creation.

The useful thing of this feature is that the application layer does not have to worry about
how the token it is handling has been obtained (which flow) because they are all the same
and contain the same claims set and can be used the same way (ie invoke the standard userinfo
endpoint) .

For each claim Keycloak allows to choose whether to include it in ID Token , Access Token or User Info, see the screenshot

[aeneasr]

I see, that makes it clearer. I don't think that we'll add this feature in the foreseeable future though as the concept of Service Accounts may or may not be part of the overall identity model you have in your business. What hydra does do is implement the RFCs according to specs and none of the specs have the concept of a Service Account.

How you retrieve metadata about a certain session is really up to you. Hydra offers a way to specify this metadata for flows that are not client_credentials grants and put that in an access/id token, but it does not have a conceptual model of an OAuth2 Client being a substitute for an identity. You can obviously always use the sub field of the access token to pull additional data for that subject from a custom datastore, but I do not see that as the responsibilty of Hydra.

ID Tokens in general are for real end-users, not for pure programmatic clients. While some platforms might choose to implement this as an enterprisy feature on top of the original spec, that's not something I want to do here. One reason being complexity, and the other being that I think it's an opinionated decision to allow that.

I'm certainly sure that you can implement this type of behavior with Hydra with some custom code - so it is possible, but I don't think this belongs into the core product.

[pluservice]

I'm glad that we managed to understand each other, the proposal wanted to go in the direction of enriching hydra with advanced features but I respect your decisions