In order to further improve behavior for Internet-scale requirements,
we add layered system constraints (Figure 5-7). As described in
Section 3.4.2, the layered system style allows an architecture to be
composed of hierarchical layers by constraining component behavior
such that each component cannot "see" beyond the immediate layer with
which they are interacting. By restricting knowledge of the system to
a single layer, we place a bound on the overall system complexity and
promote substrate independence. Layers can be used to encapsulate
legacy services and to protect new services from legacy clients,
simplifying components by moving infrequently used functionality to a
shared intermediary. Intermediaries can also be used to improve system
scalability by enabling load balancing of services across multiple
networks and processors.
The primary disadvantage of layered systems is that they add overhead
and latency to the processing of data, reducing user-perceived
performance [32]. For a network-based system that supports cache
constraints, this can be offset by the benefits of shared caching at
intermediaries. Placing shared caches at the boundaries of an
organizational domain can result in significant performance benefits
[136]. Such layers also allow security policies to be enforced on data
crossing the organizational boundary, as is required by firewalls
[79].
The combination of layered system and uniform interface constraints
induces architectural properties similar to those of the uniform
pipe-and-filter style (Section 3.2.2). Although REST interaction is
two-way, the large-grain data flows of hypermedia interaction can each
be processed like a data-flow network, with filter components
selectively applied to the data stream in order to transform the
content as it passes [26]. Within REST, intermediary components can
actively transform the content of messages because the messages are
self-descriptive and their semantics are visible to intermediaries.
You should really read the layered system part of the Fielding dissertation.
Where exactly is REST authentication used?
It is used between a REST client and a REST service (the client sends requests - containing auth headers - to the service). A REST client can be on a browser, on another server, on your server (e.g. a load balancer), etc... It depends on the current context what is a REST client and what is a REST service. By REST you have a layer hierarchy in which the upper layer contains the clients which call the services of the next layer below, and so on... The components (clients, services) of this structure does not know of the existence of the layer hierarchy...
So for example it can happen, that a proxy relays the requests to the next layer without authorization, because authorization will be done by other components. It can happen that you authenticate your clients and add a secondary auth header with user identity, or permissions, so the layers below don't have to process username and password again. There are many options...
Just to talk about oauth. It is for authorizing access of 3rd party (non-trusted clients) to user accounts. So in that case the client runs on a different server, and it sends an access token (instead of username and password) registered by an user. This 3rd party client uses the allowed part of the permissions of that user. Many user can register the same 3rd party client with different access tokens ofc.
