Introduction to ONVIF Profile V Uplink Authentication Modes

General
1

1
1850×460 362 KB

The authentication mechanisms in ONVIF Profile V are quite extensive, and organizing all these modes during testing turned out to be quite a brain-twister.
The documentation covers both OAuth2 and Uplink authentication. Here, we will use Uplink as the main thread for our analysis. Uplink supports the following two modes:

  1. mTLS requires pre-configuring corresponding certificates on both the device and the cloud. Of course, the cloud can use a single unified certificate for all devices, while device certificates require a “one-certificate-per-device” (unique per-device credential) setup.
    xml
<SetUplink xmlns="http://www.onvif.org/ver10/uplink/wsdl">
  <Configuration>
    <RemoteAddress>wss://10.168.1.195:21574</RemoteAddress>
    <CertificateID>Cert-faeb526c-df37-11f1-b259-e454e89daf79</CertificateID>
    <UserLevel>Administrator</UserLevel>
    <CertPathValidationPolicyID>Policy-f79ca0fc-df37-11f1-91ca-e454e89daf79</CertPathValidationPolicyID>
  </Configuration>
</SetUplink>

Use code with caution.
2. OAuth2 is further divided into the following three sub-modes:
• a. client_secret_basic
• b. private_key_jwt
• c. mtls (tls_client_auth)
Among these three modes: Mode a does not require pre-configuring corresponding certificates on the server, though it does require setting a clientID and clientSecret. There are multiple ways to implement this, such as sharing one client_secret across a batch of devices, or assigning one client_secret per device (unique per-device credentials). Mode b requires pre-configuring the corresponding device public key certificates on the server, and of course, each device must also have its own certificate set up in advance—this must strictly follow a unique per-device credential approach. Mode c requires both the device and the server to have their respective certificates pre-configured.
xml

<SetUplink xmlns="http://www.onvif.org/ver10/uplink/wsdl">
  <Configuration>
    <RemoteAddress>wss://10.168.1.195:21650</RemoteAddress>
    <UserLevel>Administrator</UserLevel>
    <CertPathValidationPolicyID>Policy-1efac5e8-df38-11f1-9b55-e454e89daf79</CertPathValidationPolicyID>
    <AuthorizationServer>AuthSrv-1ed32f42-df38-11f1-8ef9-e454e89daf79</AuthorizationServer>
  </Configuration>
</SetUplink>

<CreateAuthorizationServerConfiguration xmlns="http://www.onvif.org/ver10/advancedsecurity/wsdl">
  <Configuration Type="OAuthClientCredentials" ClientAuth="client_secret_basic">
    <ServerUri>https://10.168.1.195:20885/.well-known/openid-configuration</ServerUri>
    <ClientID>client1</ClientID>
    <ClientSecret>client-secret1</ClientSecret>
    <Scope>scope1</Scope>
    <CertPathValidationPolicyID>Policy-d61ad61c-df35-11f1-8b0b-e454e89daf79</CertPathValidationPolicyID>
  </Configuration>
</CreateAuthorizationServerConfiguration>

Use code with caution.
Summary
Aside from the client_secret_basic mode—which bypasses having to configure a certificate for every single device on the server—all other methods require unique per-device credentials. Since client_secret_basic is not recommended, you should aim for a unique per-device credential design as much as possible when architecting for Profile V.
When scaling a service to handle tens of thousands, or even hundreds of thousands to millions of devices, performance becomes critical. You can leverage OAuth2’s scope for partitioning to boost server performance—partitioning is much harder to achieve without OAuth2. Therefore, our recommended approaches are private_key_jwt and mtls (tls_client_auth), allowing the server to partition based on scope to improve lookup speeds.