A service client is a specialized OA4MP client that complies with section 2.1 of RFC7523. This means that it is allowed to directly issue a token request without authentication. However, this implies a trust relationship and requires vetting.
As computing switches to token-based trust models and leaves behind X.509 certificates, services still need to be able to identify themselves and there need to be trust relationships in effect. Before, a server would have an X.509 certificate to prove who or what it was and now it needs a signed token. Requiring a service (and its human administrator) to go through an OAuth flow every time, say, a server restarts, is an intolerable burden on a system. Therefore, the trust is agreed upon separately with a service client. Typically, a service client has a single user and restricts which users can be recognized. Public/private keys must be generated and all authentication is key-based. Once all is in place, the service simply issues a grant request (which is in JSON and also signed with the private key) to the token endpoint, signed with its keys, and gets tokens back.
As per the spec., section 2.2, a service client must use client authentication. This is in addition to it signing its grant request.
This request replaces the authorization grant request from OAuth. Section 2.1 of RFC7523 lists the requirements. Note that the subject is effectively the username. The list of allowed users may be restricted by setting it in the server's client configuration. In addition, you may include the following parameters:
| Attribute | Required? | Default | Description |
| at_lifetime | N | -- | Request time for the access token to be valid. Note this is subject to server restrictions. See note on units. |
| audience | N | -- | A single string or multiple values. These are compliant with RFC 8693 (token exchange). |
| extended attributes | N | -- | Any OA4MP extended attributes. |
| resource | N | -- | A single URI or multiple values. These are compliant with RFC 8693 (token exchange). |
| rt_lifetime | N | -- | Request time for the refresh token to be valid. Note this is subject to server restrictions. See note on units. |
| scope | N | -- | A single scope or array of scopes. |
A typical JSON request would be
{
"iss": "ashigaru:command.line2",
"sub": "jeff",
"jti": "ashigaru:command.line2:/rfc7523/GmGUmD4J0JZH1oAkqNgkeTpWpqklq2HCJi38SuUNV-U",
"exp": 1686595091,
"iat": 1686594191,
"scope": [
"org.cilogon.userinfo",
"openid",
"profile",
"email"
],
"oa4mp:/roles": "admin,all-user",
"at_lifetime": 1000000,
"rt_lifetime":"10 days",
"redirect_uri": "https://oauth.bigstate.edu/client2/ready",
"nonce": "1yv5JQ5sElsxDHTcObWhJGBp6uy0i4VwMgV4vCHou1I"
}
Note that this would be turned into the payload of a JWT and signed with the client's private key before being sent to the server.
If you are scripting, then immediately after these are done you may invoke a script in the post or pre_auth phase.
You may also use key authentication with the device flow, the single difference is that the audience must be the device flow endpoint, not the token endpoint.