What AuthRequest Is
AuthRequest is the authorization request service in BACnet, defined in Clause 17.6 of ANSI/ASHRAE 135-2024, part of the authentication and authorization clause added to protect sensitive operations. A client uses it to obtain an access token from an authorization server so it can later perform protected operations, such as writing control commands or changing configuration, on a target device. It is a confirmed service: the server returns a token on success or an error on failure.
Most BACnet operations are open and need no token; a smaller set are protected, and those require both an authenticated client and a policy that authorizes the operation. AuthRequest is how a client acquires the token that carries that authorization. Tokens are bound to the specific client that requested them, so they cannot be used if stolen, and they are signed so they cannot be forged.
How It Works
The client sends an access token request naming the client device instance the token is to be bound to, an audience (the devices or groups where the token may be used), and an optional scope (the requested set of authorizations). The authorization server evaluates its policy and returns an access token, which may carry a narrower scope than was requested. If no scope is supplied, the server returns the default scope configured for that client and audience, or an error if no default exists. A client can also receive tokens by local configuration instead of ever issuing AuthRequest; using the service is optional for a client.
Where You’ll See It
- Protected writes and configuration. Before a client commands or reconfigures a device that enforces authorization, it obtains a token scoped to that operation.
- Zero-trust deployments. On networks where devices are not treated as trusted peers, protected operations are validated per request rather than assumed safe inside a perimeter.
- Helper flows. A tool retrieves a token bound to another device instance, the “on behalf of” pattern, so that device can present it when acting.
AuthRequest Error Codes
Clause 17.6 defines the error class and code an authorization server returns when it cannot grant the request. The general error model lives in Clause 18 of the standard.
| Situation | Error class | Error code |
|---|---|---|
| The device is not configured to grant access tokens | SERVICES | OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED |
| The server has no policies for the requested audience | SERVICES | UNKNOWN_AUDIENCE |
| The server has no policies for the requested client | SERVICES | UNKNOWN_CLIENT |
| The server does not recognize the requested scope | SERVICES | UNKNOWN_SCOPE |
| No scope was requested and no default scope matches the client and audience | SERVICES | NO_DEFAULT_SCOPE |
| The server has no policy allowing the requested combination of parameters | SERVICES | NO_POLICY |
Reading these in the field:
UNKNOWN_CLIENT,UNKNOWN_AUDIENCE, andNO_POLICYall point to authorization policy that has not been configured on the server for this client, target, or operation; they are policy gaps, not protocol faults.NO_DEFAULT_SCOPEmeans the request omitted a scope and the server has no configured default for that client and audience; supply an explicit scope.- No response at all is not a service error. A timeout is a transport or addressing problem, not an authorization problem.
Profiles That Require It
Executing AuthRequest (AA-AS-B) is required only of the authorization-server profile B-AS. Authorization is optional, specialty functionality across the rest of the profile set, so most devices neither grant nor request tokens and declare no support in their PICS (Protocol Implementation Conformance Statement).
What Chipkin Provides
AuthRequest and the BACnet authorization model are part of Chipkin’s BACnet security roadmap rather than a shipping capability today. Talk to us about adding BACnet client or server support to your device.