[id="proc-using-service-account_{context}"]

[[_service_accounts]]
= Using a service account
[role="_abstract"]
Each OIDC client has a built-in _service account_. Use this _service account_ to obtain an access token.

.Prerequisites

.Procedure
. Click *Clients* in the menu.  
. Select your client.
. Click the *Settings* tab.
. Toggle <<_access-type, Client authentication>> to *On*.
. Select *Service accounts roles*.
. Click *Save*.
. Configure your <<_client-credentials, client credentials>>.
. Click the *Scope* tab.
. Verify that you have roles or toggle *Full Scope Allowed* to *ON*.
. Click the *Service Account Roles* tab
. Configure the roles available to this service account for your client.

Roles from access tokens are the intersection of:

* Role scope mappings of a client combined with the role scope mappings inherited from linked client scopes.
* Service account roles.

The REST URL to invoke is `{kc_realms_path}/{realm-name}/protocol/openid-connect/token`. This URL must be invoked as a POST request and requires that you post the client credentials with the request.

By default, client credentials are represented by the clientId and clientSecret of the client in the *Authorization: Basic* header but you can also authenticate the client with a signed JWT assertion or any other custom mechanism for client authentication.

You also need to set the *grant_type* parameter to "client_credentials" as per the OAuth2 specification.

For example, the POST invocation to retrieve a service account can look like this:

[source,subs=+attributes]
----

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

    grant_type=client_credentials
----

The response would be similar to this https://datatracker.ietf.org/doc/html/rfc6749#section-4.4.3[Access Token Response] from the OAuth 2.0 specification.

[source]
----

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache

{
    "access_token":"2YotnFZFEjr1zCsicMWpAA",
    "token_type":"bearer",
    "expires_in":60
}
----

Only the access token is returned by default. No refresh token is returned and no user session is created
on the {project_name} side upon successful authentication by default. Due to the lack of a refresh token, re-authentication is required when the access token expires. However, this situation does not mean any additional overhead for the {project_name} server because sessions are not created by default.

In this situation, logout is unnecessary. However, issued access tokens can be revoked by sending requests to the OAuth2 Revocation Endpoint as described in the xref:con-oidc_{context}[OpenID Connect Endpoints] section.

[role="_additional-resources"]
.Additional resources
For more details, see <<_client_credentials_grant,Client Credentials Grant>>.
