Skip to content

Network Setup⚓︎

Default Network Setup (Using Traefik)⚓︎

The Traefik configuration included in the standard nextAuth Docker setup will automatically configure a Traefik reverse proxy, which will map incoming connections to the other containers.

Incoming Network Connections⚓︎

The table below lists the (default) ports that each Docker image will listen on.

Docker Image Port (TCP) Usage TLS Port Exposure
ns 8080 REST API Optional Open towards business applications using REST API
ns 9999 WebSocket Optional Public
ns, sfs, mc 8888 Mobile API WebSocket Optional Public
mc 8080 REST API - Connections from NS Optional Open to NS.
mc 9090 gRPC API - Connections from NS Optional Open to NS.
ns, sfs, mc 9613 Admin (Prometheus Metrics, Liveness and Readiness) - Internal
mgmt* 80 HTTP, server management web interface. -
mgmt* 81 HTTP, account management web interface. -
mgmt* 82 HTTP, identity provider web interface. -

(*) Optional

By default. the ports of the containers are not exposed outside of the local service network created by Docker Compose. Traefik is an open source reverse proxy and load balancer, which features a powerful configuration discovery mechanism that is compatible with Docker and Kubernetes. In a Docker-based setup, it can be configured dynamically by assigning object labels to containers. Alternatively, Traefk can also be used as an ingress controller in Kubernetes setups. Fore more information on how to configure Traefik, we refer to its docs. Finally, we want to stress that the Authentication Server is compatible with any reverse proxy and we provide the Traefik-based setup only as a reference design.

Outgoing Network Connections⚓︎

Only the ns and mc will make connections to the outside world.

Docker Image host:port Usage
mc fcm.googleapis.com:443 Push Messages (Android)
mc api.push.apple.com:443 Push Messages (iOS)
mc api.sandbox.push.apple.com:443 Push Messages (iOS - Development)
ns license.nextauth.com:443 License Validation Server
ns, sfs, mc \<db server>:\<db port> Database connection, depends on database setup.
ns \<redis server>:\<redis port> Redis connection, depends on Redis setup.
ns \<mc>:8080 Messaging
ns \<mc>:9090 Messaging

Manual Network Setup (Without Traefik)⚓︎

Mapping Ports⚓︎

When not using Traefik all mappings will need to be set up manually on a reverse proxy (e.g., load balancer). The mapping below is only an example of a potential setup.

Incoming URL Mapping Remarks
wss://nextauth.mydomain.com/ns/websocket ns:9999 Make sure NEXTAUTH_DEFAULT_WEBSOCKET_URI matches the configured URL.
wss://nextauth.mydomain.com/ns/sigmai ns:8888 Make sure NEXTAUTH_DEFAULT_SIGMAI_URI matches the configured URL.
wss://nextauth.mydomain.com/mc/sigmai mc:8888
wss://nextauth.mydomain.com/sfs/sigmai sfs:8888
https://ns-api.nextauth.mydomain.com ns:8080 Optional. Opening up the REST API can be a security risk. To support TLS Peer Verification, forward the port without TLS termination and use a separate subdomain to make sure SNI proxying works.
https://mc-api.nextauth.mydomain.com mc:8080 Optional. To support TLS Peer Verification, forward the port without TLS termination and use a separate subdomain to make sure SNI proxying works.
https://dashboard.nextauth.mydomain.com mgmt:80 Optional. Makes the Dashboard available.
https://account.nextauth.mydomain.com mgmt:81 Optional. Makes the Account Management available.
https://idp.nextauth.mydomain.com mgmt:82 Optional. Makes the Identity Provider available.

TLS termination can take place on the reverse proxy, except when using TLS Peer Verification on the NS/MC REST API. Optionally, a new TLS connection can be set up from the reverse proxy to the containers. TLS termination has no impact on the security of the authentication taking place between the Mobile SDK and the NS/SFS/MC, which is completely independent of the usage of TLS.

TLS Configuration⚓︎

Supported Endpoints⚓︎

All endpoints of the NS, SFS and MC support TLS with server authentication. The API endpoints of the NS and MC also support mutual authentication.

The configuration variables NEXTAUTH_<server>_<endpoint>_TLS_KEY(_FILE) and NEXTAUTH_<server>_<endpoint>_TLS_CERTIFICATE(_FILE) can be used to configure a PEM-encoded TLS key and certificate, where <server> refers to the server component (NS, SFS or MC) and <endpoint> the endpoint (i.e., ADMIN, GRPC, HTTP, SIGMAI, or WEBSOCKET).

Supported TLS Versions and Cipher Suites⚓︎

TLS version 1.2 and 1.3 are supported.

For TLS 1.2 cipher suites are restricted to the following:

  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305;
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305;
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256;
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

ECDHE with curve P256 or X25519 is preferred.

For TLS 1.3 the cipher suites are standardized and no longer configurable.

Client Authentication using TLS⚓︎

The API endpoints of the NS and MC support TLS mutual authentication. In this case the client will require a TLS private key and certificate.

A distinction needs to be made between connecting to the API endpoint and receiving permissions to perform API calls.

When it comes to allowing a client to connect to the API endpoint, there are three options:

  • Free connection, even without client certificate. A client certificate can optionally be presented by the client.
  • A client certificate is required, but not necessarily signed by a specific CA.
  • A client certificate signed by a specific CA is required.

After connecting (which is allowed depending on the above options), the server will need to determine whether to grant access to the requested API calls. There are only two options available here:

  • The client authenticates using an API key.
  • The client authenticates using the client certificate (TLS Peer Verification). The client certificate will need to be listed explicitly in the NS/MC database, along with the associated roles and permissions.

Note that the NS/MC will never grant access based only on a certificate being signed by a certain CA.