70 lines
2.9 KiB
Text
70 lines
2.9 KiB
Text
[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>>.
|