[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* checkbox to make sure it is enabled.
. Click *Save*.
. Configure your <<_client-credentials, client credentials>>.
. Click the *Client Scopes* tab, select the dedicated client scope (usually first client scope in the list, more details <<_client_scopes_dedicated,in this section>>) and select *Scope* tab of the client scope.
. Verify that you have roles or toggle *Full Scope Allowed* to *ON*. Note that this switch is useful only for the development purposes and in the production, it is recommended to disable this switch and properly configure role scopes. The details about this switch are described in <<_role_scope_mappings, this section>> and in <<_oidc_token_role_mappings,this section>>.
. Click the *Service Account Roles* tab of your client
. 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
----

Note that the value of `cHJvZHVjdC1zYS1jbGllbnQ6cGFzc3dvcmQ=` used in the `Authorization` header is Base64 encoded value of clientId and clientSecret
in the format prescribed by the `Authorization: Basic` header. In this example, the client ID is `product-sa-client` and the client secret was `password` and hence the value was obtained for example
by this command in the Unix platform:
[source,bash]
----
echo 'product-sa-client:password' | base64
----
Instead of using the header `Authorization: Basic`, it is also possible to send the credentials as parameters `client_id` and `client_secret` of the POST request. For other client credentials methods,
the format of the parameters would be different as described above.

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":"eyJhbGciOiJSUzI1NiIs...",
    "token_type":"Bearer",
    "expires_in":60,
    "scope": "email profile"
}
----

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>>.
