It is now a best practice to start using RESTCONF API instead of the legacy pre-standard-REST as a lot of new features are only available in RESTCONF.
Particularly, for RESTCONF you can support token-based authentication (see attached output from "man ncs.conf"). However, this is not well documented yet.
Just in case you were thinking about it, NSO does not support client-certificate based authentication.
When authenticating via AAA external-authentication or external-validation and a token is returned,
it is possible to include a header with the token in the response.
/ncs-config/restconf/token-response/x-auth-token (boolean) [false]
Either 'true' or 'false'. If 'true', a x-auth-token header is included in the response with any
token returned from AAA.
Configuration of RESTCONF token cookies.
/ncs-config/restconf/token-response/token-cookie/name (string) 
The cookie name, exactly as it is to be sent. If configured, a HTTP cookie with that name is
included in the response with any token returned from AAA as value.
/ncs-config/restconf/token-response/token-cookie/directives (string) 
An optional string with directives appended to the cookie, exactly as it is to be sent.
Your answer is on RFC8040, section 2.2:
Given the nearly ubiquitous support for HTTP over TLS [RFC7230], RESTCONF implementations MUST support the "https" URI scheme, which has the IANA-assigned default port 443. RESTCONF servers MUST present an X.509v3-based certificate when establishing a TLS connection with a RESTCONF client. The use of X.509v3-based certificates is consistent with NETCONF over TLS [RFC7589].
HTTS is mandatory for RESTCONF.