Ecosystem SSO & OAuth 2.1 Architecture
How downstream applications authenticate with NSGO using OAuth 2.1 and PKCE S256.
#The Single Sign-On (SSO) Flow
When you click "Sign in with NSGO" on an ecosystem application (such as the NSGO IP Logger):
1. The client application generates a cryptographically random PKCE code_verifier and computes its SHA-256 hash (code_challenge).
2. The browser is redirected to NSGO: /api/oauth/authorize?client_id=...&response_type=code&code_challenge=...&code_challenge_method=S256.
3. If you have an active NSGO session, NSGO verifies the client registry. If first-time authorization is required, the Consent Screen (/oauth/consent) is displayed.
4. NSGO issues a single-use authorization code (valid for 5 minutes).
5. The client application exchanges the code and code_verifier at /api/oauth/token.
6. NSGO validates the PKCE hash, consumes the authorization code (preventing replay attacks), and issues an RS256-signed ID token and access token.
#Security Guarantees of the Protocol
• RFC 7636 PKCE S256 Mandated: Implicit grant flows and plain text challenges are prohibited.
• RS256 Asymmetric Signing: Client applications verify tokens using NSGO's public JWKS keys (/.well-known/jwks.json). Private keys never leave the secure server.
• Session Isolation: Signing out of a connected application terminates only that application's local session—your central NSGO master session remains unaffected.