Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)
Extracted elements (31)
CBOR replaces JSON and CWT replaces JWT because IoT devices are constrained in processing, memory, and bandwidth. CBOR's binary encoding produces significantly smaller messages and requires less processing than text-based JSON, making it suitable for low-power and low-bandwidth devices.
It is RECOMMENDED that an RS stores only one token per PoP key, with a new token superseding the old one. This simplifies constrained implementations (reducing storage and resolution complexity) and avoids contradictory permissions or premature expiry creating security gaps.
Proof-of-possession (PoP) tokens are the default instead of bearer tokens because IoT tokens may traverse untrusted networks or be stored on constrained devices. PoP requires the client to demonstrate possession of a key bound to the token, providing security even if the token is intercepted.
The OAuth 2.0 authorization endpoint (interactive resource-owner flows) is out of scope for ACE-OAuth because the primary use case is machine-to-machine interactions that do not involve a resource owner in the real-time authorization flow.
ACE profile implementations are interoperable only with other implementations of the same profile; implementations of different profiles are not expected to interoperate. More capable devices (e.g., smartphones) may implement multiple profiles to interact with a wider range of constrained devices.
The use of CoAP as a replacement for HTTP is RECOMMENDED for constrained environments. When future profiles use protocols that do not support RESTful verbs (GET, POST), those profiles MUST specify how the corresponding protocol messages are transmitted instead.
A client receiving a cnonce in AS Request Creation Hints MUST include it in the access token request to the AS. The AS MUST include the cnonce value in the issued access token. An RS using the client-nonce mechanism MUST verify the token contains a fresh cnonce claim; otherwise it MUST discard the token and respond with 4.01 (Unauthorized).
A client using the authz-info method MUST POST the access token to the RS's authz-info endpoint. The RS MUST verify the token before storing it; if valid, the RS MUST respond with CoAP 2.01 (Created). The RS MUST be prepared to store at least one access token for future use.
All communications between ACE entities (C-AS, C-RS, RS-AS) MUST be encrypted, integrity protected, and protected against message replay. Communicating endpoints MUST perform mutual authentication, and responses MUST be bound to requests.
Communication between a requesting entity and the introspection endpoint MUST be integrity protected, encrypted, and request-response bound, with mutual authentication. For an invalid or inactive token query, the AS MUST respond with an introspection response with active set to false rather than an error.
For self-contained tokens, the RS MUST process the security protection first (COSE for CWT, JOSE for JWT) and MUST verify that the token was generated by an AS authorized to issue access tokens for this RS.
In CBOR-encoded token requests and responses, all OAuth parameters MUST be mapped to CBOR integer abbreviations as specified in Table 5. Grant types and error codes MUST likewise use their registered CBOR integer abbreviations in CBOR payloads.
Profiles MUST specify a communication security protocol between the client and RS providing encryption, integrity, replay protection, and request-response binding. Profiles MUST also specify a RECOMMENDED security protocol for C-AS and RS-AS communications.
Proof-of-possession-based refresh token requests MUST NOT request different proof-of-possession keys or different audiences. Refresh tokens can only obtain access tokens bound to the same PoP key and audience as the initial token request.
The AS MUST reject a token request with error 'unsupported_pop_key' (CoAP 4.00) if the client submits an asymmetric key the RS cannot process. If the client and RS share no common profile, the AS MUST reject with error 'incompatible_ace_profiles' (CoAP 4.00).
The RS MUST treat any request for a protected resource as an Unauthorized Resource Request when: the request arrives on an unsecured channel, the RS has no valid access token for the sender, or the token does not authorize the requested action on the resource. Such requests MUST be denied with an 'unauthorized_client' error.
When CoAP is used for the token or introspection endpoints, the sender MUST encode request parameters as a CBOR map submitted as the payload of a POST request, rather than using URI-query parameters. Profiles using CBOR at the outermost layer MUST use Content-Format 'application/ace+cbor' (CoAP ID: 19).
Section 7 of RFC 9200 addresses privacy considerations for ACE-OAuth, including the potential for access tokens and introspection exchanges to expose client identity, usage patterns, and resource-access behavior across IoT deployments.
AS Request Creation Hints is a CBOR or JSON map sent by the RS in response to an Unauthorized Resource Request. Optional fields: AS (absolute URI, CBOR key 1), kid (key identifier, key 2), audience (key 5), scope (key 9), cnonce (client-nonce, key 39). It helps the client discover and contact the correct AS.
The authz-info endpoint, implemented by the RS at default path '/authz-info', accepts POST requests carrying an access token. It is not itself a protected resource and MUST NOT be protected as such. The RS stores the verified token for subsequent client authorization decisions.
The introspection endpoint at the AS accepts POST requests from RS or client, returning token metadata: active status, scope, ace_profile (integer), cnonce (byte string), cti (token ID, byte string, CBOR key 7), exi (extended expiry, CBOR key 40), and PoP key material via cnf. Default path SHOULD be '/introspect'.
The token endpoint at the AS accepts client POST requests; grant_type defaults to 'client_credentials' if absent. The AS responds with Access Information: access_token, ace_profile, expires_in, and PoP key material (cnf / rs_cnf from RFC 9201). The default endpoint path SHOULD be '/token'.
RFC 9200 establishes or updates multiple IANA registries: ACE Authorization Server Request Creation Hints, OAuth Error Code CBOR Mappings, OAuth Grant Type CBOR Mappings, OAuth Access Token Types (adding 'PoP'), OAuth Access Token Type CBOR Mappings, ACE Profiles, OAuth Parameters CBOR Mappings (Table 5), and OAuth Token Introspection Response CBOR Mappings (Table 6).
Access tokens MUST be integrity protected. When a symmetric PoP key is included in the token, either the whole token or the key alone MUST be encrypted. Confidentiality protection of token content is layered on top of transport-level security.
AS Request Creation Hints are sent unprotected (before a security association is established) and could be modified by an attacker to redirect the client to a malicious AS. Clients MUST independently validate that the indicated AS is authorized to issue tokens for the RS.
Denial-of-service attacks against or using the introspection endpoint are a concern: an attacker may flood the RS to trigger excessive introspection calls to the AS, or flood the AS's introspection endpoint directly. Profiles should consider rate limiting and authentication of introspecting entities.
The audience claim restricts an access token to specific resource servers. RS implementations MUST validate the audience claim to prevent a token intended for one RS from being replayed at another RS.
CBOR mappings for token introspection parameters (Table 6): JWT/CWT claims iss/sub/aud/exp/nbf/iat at keys 1-6, cti (key 7, byte string), scope (key 9), active (key 10, boolean), token (key 11, byte string), ace_profile (key 38, integer), cnonce (key 39, byte string), exi (key 40, unsigned integer).
CBOR parameter mappings for token requests/responses (Table 5): access_token (key 1, byte string), expires_in (key 2, unsigned integer), audience (key 5, text string), scope (key 9, text or byte string), client_id (key 24), ace_profile (key 38, integer), cnonce (key 39, byte string). Integer keys in range -24 to 23 use 1-byte CBOR encoding.
Error code CBOR abbreviations (Table 3): invalid_request=1, invalid_client=2, invalid_grant=3, unauthorized_client=4, unsupported_grant_type=5, invalid_scope=6; plus two new ACE-OAuth codes: unsupported_pop_key=7 and incompatible_ace_profiles=8.
Grant type CBOR abbreviations (Table 4): password=0, authorization_code=1, client_credentials=2, refresh_token=3. These integer values MUST replace string values when CBOR payloads are used.