The main advantages of the side car proxy are: 

1) It is independent from the primary application in terms of environment and programming language 

2) A sidecar can access the same resources as the primary application. It can even be used for monitoring. 

3) There is no latency in the communication between the side car proxy and the main application 

4) When the applications don't provide an extensibility mechanism, the side car can extend the functionality often in its own container. 

NGINX has always been a reverse proxy. The authentication provided by a reverse proxy is not available from Kubernetes Services.  Therefore, a reverse proxy is sometimes run in the same pod as the application in a side car container. The side car proxy is exposed only to the world outside the pod while keeping the connection between the application and the proxy private. Envoy proxy demonstrates this and the Istio plugin injects this proxy inside the pod. All http port 80 traffic then goes through the pod and a corresponding request is made to the application. Unless the traffic entering the side-car proxy has basic authentication, it does not make a request to the application. 

# Kubernetes deployment to deploy Sidecar proxy + application in a single pod,  

apiVersion: apps/v1 

kind: Deployment 

metadata: 

name: nginx-deployment 

labels: 

app: example-application 

spec: 

replicas: 1 

selector: 

matchLabels: 

app: example-application 

template: 

metadata: 

labels: 

app: example-application 

spec: 

containers: 

- name: sidecar-proxy 

image: example-application-sidecar-proxy 

imagePullPolicy: Always 

ports: 

- containerPort: 80 

- name: application 

image: example-application 

imagePullPolicy: Always 

The basic auth used with the proxy can be specific to clients and not necessarily to the users. Any Identity Access Module can authenticate and authorize the user which can then then translate to a token over client communications with the application.  This is called client credential workflow where the clients treat a guest user or an identified user the same and an IAM module is responsible to ensuring only valid users are able to access the client. Thus, user sends requests from outside world to the IAM, then to the client, then to the proxy and finally to the application.