无UI网站的IdentityServer：分离认证、授权与资源服务架构问询

Great question! Let's walk through how to build this decoupled, role-separated architecture using OAuth 2.0 and OpenID Connect (OIDC)—all without requiring any user-facing browser redirects. Here's a step-by-step implementation plan tailored to your requirements:

Core Architecture Ground Rules #

First, let's clarify the non-negotiable separations and roles to ensure alignment:

• CLIENT: Initiates auth/authorization requests, handles tokens (including ID_TOKEN), and accesses protected resources. Runs independently of all other roles.
• AUTHENTICATION-SERVER (AS): The single source of truth for user identity. Validates user credentials, issues ID_TOKENs, and coordinates with authorization servers. No overlap with other roles.
• AUTHORIZATION-SERVER (AZS): Deployed as a scalable cluster. Validates client identities, issues access tokens, and enforces permission policies. Multiple instances share state via a centralized datastore or config system.
• RESOURCE-SERVER (RS): Deployed as a scalable cluster. Validates access tokens and serves protected resources. Uses shared validation logic across all instances.

No-Redirect OIDC Auth + Authorization Flow #

Since browser redirects are off-limits, we'll use OIDC Backchannel Authentication (ideal for untrusted clients) or OAuth 2.0 Resource Owner Password Credentials Grant (for highly trusted internal clients). Below is the backchannel flow (more secure for most use cases):

1. Client Initiates Backchannel Auth Request #

The client sends a direct POST request to the AS, including its own credentials, user authentication details, and requested scopes (must include openid to trigger ID_TOKEN issuance):

POST /as/backchannel/authenticate HTTP/1.1
Host: your-authentication-server.com
Content-Type: application/x-www-form-urlencoded

client_id=your-confidential-client-id&client_secret=your-client-secret&
username=user@example.com&password=user-secure-password&
scope=openid+profile+resource.read&response_type=id_token+token

2. AS Validates Identity & Coordinates with AZS #

• The AS verifies the user's credentials (e.g., against a user database or LDAP).
• Once authenticated, the AS generates a signed ID_TOKEN (contains user claims like sub (user ID), name, email, and metadata like iss (AS URL), aud (client ID), exp (expiry)).
• The AS then calls the AZS's internal API to request an access token, passing the authenticated user's ID and requested scopes.
• The AZS validates the AS's identity (via pre-shared secrets or mutual TLS) and issues a short-lived access token.

3. Client Receives & Validates Tokens #

The AS returns both the ID_TOKEN and access token to the client. The client must:

• Verify the ID_TOKEN's signature using the AS's public keys (fetched from its /.well-known/jwks.json endpoint).
• Confirm the ID_TOKEN's aud matches the client's ID, iss matches the AS's URL, and exp is in the future.

Example validation logic (pseudocode):

import jwt
from jose import jwk, jwt
from jose.utils import base64url_decode

def validate_id_token(id_token, jwks, client_id, issuer):
    header = jwt.get_unverified_header(id_token)
    key = next(k for k in jwks if k["kid"] == header["kid"])
    public_key = jwk.construct(key)
    payload, signature = id_token.rsplit('.', 1)
    decoded_signature = base64url_decode(signature.encode('utf-8'))
    
    if not public_key.verify(payload.encode('utf-8'), decoded_signature):
        raise ValueError("Invalid ID_TOKEN signature")
    
    claims = jwt.decode(id_token, key, audience=client_id, issuer=issuer, algorithms=['RS256'])
    return claims

4. Client Accesses Protected Resources #

The client includes the access token in the Authorization header when calling any RS instance:

GET /rs/api/protected-data HTTP/1.1
Host: your-resource-server.com
Authorization: Bearer your-access-token

The RS validates the access token by either:

• Calling the AZS's /introspect API to check token validity and permissions, or
• Locally verifying the token's signature (if it's a JWT) using the AZS's public keys.

Scaling AZS & RS Clusters #

• AZS Cluster: Ensure all instances share the same signing keys (use a centralized secrets manager) and client registration data (use a shared database). This lets any AZS instance validate tokens issued by another.
• RS Cluster: For performance, prefer local JWT validation over introspection calls. Configure all RS instances to fetch the AZS's JWKS endpoint periodically for up-to-date public keys.

Security Best Practices #

• Use Confidential Clients: Store client_secret securely (never expose it in frontend code) and use mutual TLS for client-as/AZS communication if possible.
• Short-Lived Tokens: Set access token expiry to 15-30 minutes. Use refresh tokens to get new access tokens without re-authenticating users.
• Encrypt Sensitive Data: Use JWE (JSON Web Encryption) for ID_TOKENs if they contain sensitive user information.
• Avoid Password Grant for External Clients: Stick to backchannel auth for untrusted clients to reduce credential exposure risk.

内容的提问来源于stack exchange，提问作者Ravior