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, Traefik 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 AND oauth2.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⚓︎
We only support TLS version 1.3, which has standardised cipher suites that are 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.