Home > OpenID Connect OAuth Server by DnC > How does OIDC contribute to the ZTNA approach?

How does OIDC contribute to the ZTNA approach? Prospects for OAuthSD towards hardware level control

Zero Trust Network Access, ZTNA: "Zero-trust" access to the network. This concept formalized in 2010 by the research firm Forrester aims to give users the minimum necessary privileges (unlike access to the network by Virtual Private Network, VPN).
OpenID Connect provides certain responses in this area, in particular for in-depth protection, beyond controlling access to the network.

In the context of COVID-19, telework leads many employees to access their company network by means of a VPN tunnel from the personal computer or - absolute horror - the family computer. Checks should be made at this level.

Principles of ZTNA

It is about protecting the information system (IS) and sensitive data based on the principle that no one should be trusted. From user equipment to application, there are three general principles to apply:

1. Control of the materials used to access the IS: The sole control of the end user is not sufficient, it is also necessary to control the user agent by means of which he accesses the network and the applications.

2. Multi-factor authentication: Authentication (at least two factors, or Two Factors Authentication, TFA) requires multiple proofs of identity from the end user.

3. Minimum privilege: Give users only access to the resources or data they need to perform their tasks.

How is OpenID Connect compared to this principles?

1. OpenID Connect intervenes at the application level. OIDC cannot therefore replace the means of identifying and controlling the material layers. However, the Authorization Code Grant, when applied to "back-end" applications and services, provides a way to identify these components at the hardware level. On this subject, see: Verifying the origin of the request received by a resource server.

2. Multi-factor identification is not part of the OpenID Connect standard. The identification layer of the Authorize controller must implement several identification means, OAuthSD provides multi-factor identification.

3. By allowing identity tokens and privilege information to be conveyed by the identity token (ID Token) and guaranteeing its integrity by means of the token signature, OpenID Connect opens a means of controlling access to applications and data. OAuthSD allows the transmission of privileges.
However, it all depends on what the protected applications and resources will do with this information.

In conclusion :

Applications of the ZTNA principles most often aim to replace access by VPN, and are therefore interested in the transport layer. Identification and control of hardware integrity is still the poor relation of security solutions, OIDC adds nothing.

OpenID Connect extends security at the application level (in the upper layer of the OSI model) and therefore finds its place in a complete ZTNA approach.

However, the difficulty of OIDC lies in the need to adapt applications and protected data resources by incorporating an OIDC module into them. See: Adaptation des applications.

Prospects for the evolution of OAuthSD

Note that the OAuthSD server already integrates some security functionalities at the level of the hardware and transport layers, and will bring more and more as it is developed, the OIDC server becoming part of OAuthSD.

There is more information, sign in to view them.