Network Setup⚓︎
Incoming Network Connections⚓︎
The table below lists the (default) ports that each container will listen on.
| Container | 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 |
(*) Optional
Outgoing Network Connections⚓︎
Only the ns and mc will make connections to the outside world.
| Container | host:port | Usage |
|---|---|---|
| mc | fcm.googleapis.com:443 | Push Messages (Android) |
| mc | 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 |
Mapping Ports⚓︎
Different routes 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. |
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_<service>_<endpoint>_TLS_KEY(_FILE) and NEXTAUTH_<service>_<endpoint>_TLS_CERTIFICATE(_FILE) can be used to configure a PEM-encoded TLS key and certificate, where <service> 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.