4. Auth and OAuth

I would name four types out loud and stop until they ask for more. The Controller is HTTP-thin: it binds the body and returns 200 or 401, and it never runs SQL. The Facade orchestrates: it runs validators, then calls authenticate, and it is not a god class that also hashes passwords. The Service authenticates: it loads the user through the Repository and compares a hashed password. The Repository only loads the user row. I would clarify username and password only, and whether success is a session cookie or a JWT, because this HM card does not require a token factory unless they ask. Validation of null and format lives in the façade; the credential check is not a validator if-else pile. SOLID here is S so the Controller stays HTTP, and OCP so a new check is a new Validator class. This is Java Live Code LLD for Bhavya’s HM, not the Ylogx NestJS internship. If they then ask how I would ship it, I pick a session cookie or a short JWT; Ylogx isolation is JWT and RBAC at NestJS plus Postgres RLS for three organizational tiers.

Example. POST /login hits LoginController, then LoginFacade.login, then AuthService.authenticate, then UserRepository.findByUsername, then a hash compare. Session versus JWT is a clarify after that succeeds.

If they probe: where the hashed compare lives; session cookie versus JWT after success; this is not Login Tracker, which is unverified mentor practice.

The follow-up they asked is to remove the if-else ladder in the façade. I would introduce a Validator interface with one method, validate on LoginRequest, and each check throws or returns. The façade holds a List<Validator> and loops, then calls auth.authenticate. Non-empty, format, and maybe length are validators; a wrong password is not. Credential failure is the Service returning false or throwing AuthFailed after a Repository lookup. I would not put if (role == ADMIN) ladders in the façade, because that is RBAC on APIs and RLS on rows, which is the Ylogx story, not this login LLD. Open-closed is the point: a new check is a new class, not another else-if. If I am stuck I still say four class names plus validators as a list. Live Code is Java; Ylogx shipped TypeScript NestJS, so I do not pretend this Spring façade is the intern bot.

Example. NonEmptyValidator, then EmailFormatValidator, then LengthValidator in a list; the façade loops; then AuthService does the hash compare. Adding a “must not be a disposable domain” check is a fourth class, not a new else if.

If they probe: where credential failure lives; why an ADMIN role check is not a validator; OCP versus a switch on field names.

They asked where I would and would not use GenAI. I would not use a model as authorization, as an RLS policy, as a money total without SQL, or as rover actuation or PPE boxes. At Ylogx the natural-language prompt is the interface, and the SQL that actually runs is executed as the user’s database role so row-level security still applies. The LLM must not hold a superuser connection string, because then a prompt injection is a warehouse dump. I would use GenAI where volume is high and the answer is cheaply verifiable, such as a SQL result set or a cited RAG chunk. IQVIA Hybrid RAG plus LangSmith is the “should” story: 200+ sites and 200+ page BRDs, with traces that must not leak credentials. Ylogx SQL RAG is on the resume as +65% analysis productivity behind RLS, not because the model decides who can see the row. If they push “the bot is smart enough,” I say the bot is useful because isolation exists. This prompt is IE-asked on LC 7850431 in an R3 with k-th largest; it is not a Job 10454435 named live question.

Example. An analyst asks “revenue by region.” FastAPI proposes parameterized SQL; NestJS sets the caller’s DB role from the JWT; Postgres RLS returns only that tier’s rows. The model never opens a superuser connection.

If they probe: why the model cannot be the RBAC layer; what happens if the RAG connection is table owner; LangSmith traces and secrets.

These LP prompts are IE-asked wording; the story I tell is the Ylogx resume, not an invented fight. For Dive Deep I talk bot database latency and Redis −35% plus RLS, not SEO 403, which is prep-only. For an issue that was not my task I talk isolation and latency while building the chatbot and reports. For conflict with a teammate or manager I keep it technical: RLS in the database versus app-only checks; the resume has no named interpersonal fight and I will not invent one. For Ownership I pair three-tier RLS with 99.9% uptime, because wrong-tier data is also a critical issue. For a complex problem or POCs I contrast FastAPI, NestJS, Postgres, Redis, and RLS with “just LangChain.” Login Tracker as SDE I R2 is unverified mentor practice, not this topic. I do not invent Job 10454435 LP text.

Example. “Would you ship the SQL RAG without Postgres RLS?” No. A missed WHERE on a new report query leaks, and ALB plus ECS would scale the leak. The resume number I pair with that decision is 99.9% uptime and +65% analysis productivity behind isolation.

If they probe: names of the three tiers — stay with resume wording “3 organizational tiers as role” unless confirmed off-resume; SEO 403 is not the primary Dive Deep.

RBAC is who may call which API, and at Ylogx that lives in NestJS from the JWT. RLS is which rows Postgres returns even if the SQL is a JOIN or was generated by the LLM. The resume says RLS and RBAC for three organizational tiers as role; I do not invent labels like org, team, and user unless that is confirmed off-resume. NestJS maps the caller to the matching database role, and Postgres enforces the rows. SQL RAG must execute as the user’s DB role so RLS applies; +65% productivity is analysts stopping the wait on engineers for every slice, not a superuser bot. We still needed Redis −35% on bot database latency so security was not “add a check and ignore load,” and 99.9% uptime held. App-only RBAC is the door; RLS is the warehouse. Both layers are required.

Example. The same SELECT on facts runs for two callers. The JWT maps one caller to tier role A and the other to tier role B. Postgres policies return only that tier’s rows, including when the query is a JOIN written by the SQL RAG.

If they probe: named tier labels; SET ROLE versus a GUC; why the LLM connection cannot be table owner or superuser.

App-only RBAC fails because one missed WHERE org_id = ? on a new report query leaks, and hiding a button in the UI is not a control. SQL RAG, an ad-hoc JOIN, an admin debug session, and a replica path all skip NestJS middleware if they hit Postgres as a privileged user. If the LLM holds a service-role connection string, a prompt injection can dump the warehouse. Cached bot answers must key by tier; a shared Redis key would serve another organization’s SQL result, and the resume does not name a TTL so I will not invent one. I would not ship the bot without database RLS. Scaling with ALB and ECS without RLS scales leaks. Earn Trust and Backbone here are three organizational tiers as role, not a speech about a secret scanner I cannot source.

Example. A new KPI JOIN for the 30 dashboards passes the NestJS role check. Without RLS, that SQL returns another tier’s facts. With RLS and the user’s DB role, the JOIN still returns empty for rows outside the caller’s tier.

If they probe: Redis cache key must include tier; FORCE ROW LEVEL SECURITY; why a service-role connection string is the wrong RAG design.

Row-level security lives on the table or view: you ENABLE ROW LEVEL SECURITY and attach policies with USING for reads and WITH CHECK for writes. Enforcement is inside the engine on every SELECT, UPDATE, and DELETE, including JOINs, and including functions that run as the table owner unless you FORCE ROW LEVEL SECURITY. Session context is SET ROLE to the tier role, or SET a GUC that the policy reads with current_setting, after NestJS has authenticated the JWT. The app still authenticates; the database still filters. Table owner and superuser can bypass, so the RAG connection must not be owner or superuser. I test with fixtures that a cross-tier SELECT returns zero rows. I will not describe bypass exploits. This is why SQL RAG must execute as the user’s DB role.

Example. ALTER TABLE facts ENABLE ROW LEVEL SECURITY; a policy USING (tier_id = current_setting('app.tier_id')::int); NestJS sets that GUC from the JWT, then runs parameterized SQL on a non-owner role.

If they probe: FORCE versus ENABLE; policies on views; why the table owner bypasses unless forced; how the three org tiers bind to DB roles without inventing names.

The skills list has JWT; Ylogx NestJS is the API auth surface. The resume does not say we used sessions at Ylogx, and it does not say we used Auth0 on that intern path. My honest default is a short-lived access JWT at NestJS so ECS replicas stay stateless, with RBAC claims that select the database role, and RLS still in Postgres. A server session cookie is valid computer science if they want revoke-all-on-logout without a denylist. I would not over-build: Bhavya’s HM login can stay username and password plus session. I do not put secrets or raw PII in the JWT payload, only sub, exp, and a role or tier id. Tokens authorize the API; the LLM never holds the warehouse superuser string. GiftedBooks is a lighter JWT-or-session API for per-user PDFs at sub-300 ms and 99.5%, not three-tier warehouse RLS.

Example. Access JWT in Authorization: Bearer; NestJS verifies iss, aud, and exp; maps roles to SET ROLE; Postgres RLS filters facts. Logout is drop the token plus a short exp, or a denylist if they require instant kill.

If they probe: refresh tokens versus access TTL; denylist versus short expiry; Auth0 as a Ylogx vendor — that is a skills-list item, not an internship bullet.

Auth0 is on the resume under Frameworks, and OAuth 2.0 is under Technologies. Internship bullets never name Auth0, so I will not claim an Auth0 tenant at Ylogx. I would describe Auth0 as an authorization server with hosted login; the app is an OAuth client; the isolation story is still RLS and RBAC for three organizational tiers. A typical SPA and API uses authorization code plus PKCE against Auth0; NestJS validates the JWT iss, aud, and exp, then maps role to a Postgres role. I will not invent tenant names, rules, or MFA screens I cannot describe. If they push the dashboard, hosted login plus JWT validation is the ceiling unless confirmed off-resume. PKCE exists because a public SPA has no client secret. Client-credentials is machine-to-machine and is not how Ylogx end-user reports should run.

Example. SPA redirects to Auth0 /authorize with code_challenge and S256; callback returns code; client POST /oauth/token with the verifier; NestJS accepts Bearer access and sets the DB role. Auth0 issued the token; Postgres still enforces RLS.

If they probe: implicit grant is legacy; whether Ylogx used Auth0 in production — skills only unless confirmed; where the client secret must not live.

Secrets live in process environment on the ECS task, not in Git, not in the frontend, and not in LangSmith traces. The resume lists Web Securities and AWS ECS and Docker; I do not claim AWS Secrets Manager or KMS unless that is confirmed off-resume. The database URL, an Auth0 client secret for confidential clients only, and Azure keys for IQVIA stay on the server. A public SPA has no client secret, which is why PKCE exists. IQVIA BRDs are confidential across 200+ sites and 200+ page documents; I do not log full document text. Ylogx 99.9% is availability; Earn Trust is three-tier RLS, not a secret-scan anecdote I cannot source. I skip JWT theatre if they want Ylogx for auth depth. JWT payloads still must not carry connection strings or raw PII.

Example. The ECS task definition injects DATABASE_URL; FastAPI reads it from the process environment; the SPA only has the Auth0 client_id. LangSmith traces store a run id and a cited chunk, not the warehouse password.

If they probe: rotation without naming Secrets Manager unless confirmed; what belongs in a JWT claim; why a SPA cannot hold a client secret.

Nginx is on the skills list. Ylogx deploy bullets name CloudFront, ECS, Docker, ALB, and Route 53, so TLS died at CloudFront or ALB, not a claimed Nginx hop on that intern path. The standard role of Nginx is to terminate TLS, speak HTTP/2, and reverse-proxy to the app, with certificates on the edge and containers on a private HTTP port. The honest sentence is: I list Nginx; the intern path I can defend is CloudFront to ALB to ECS; same idea, TLS dies at the edge, not in FastAPI. Sub-210 ms on the resume is CDN and cache, not TLS algorithm trivia. I will not say I configured Nginx for Ylogx unless confirmed off-resume. Private keys stay on the terminator, not in the Git repository.

Example. Browser HTTPS to CloudFront; origin to ALB; ALB to an ECS task on a private HTTP port. The Nginx listen 443 ssl sketch is how I explain the skills item, not a Ylogx topology claim.

If they probe: certs in Git; HTTP between ALB and the task; whether FastAPI terminated TLS — it should not on this path.

Redis −35% is bot database latency for hot schema and repeat natural-language to SQL answers. The cached payload must be tier-correct, so the key includes organization or role. RLS still applies when SQL executes; the cache is not a second source of truth for another tenant’s rows. Parameterized SQL, a read-only role, a timeout, and a row cap belong on the execute path. SQL RAG must run as the user’s DB role, or a cache hit becomes a leak even when the original policy was correct. I will not walk through catalog fishing as an exploit. Dive Deep is −35% and three-tier isolation together, not SEO 403. Plus 65% productivity only holds if the bot cannot leak.

Example. Cache key shaped like tier:2|sql-hash. A tier-1 caller never reads a tier-2 value. A miss runs parameterized SQL after SET ROLE / GUC, then stores only that tier’s result.

If they probe: TTL is not on the resume so do not invent one; stampede on a hot KPI; why a shared “global SQL result” key is unsafe.

A JWT has three base64url parts separated by dots: header, payload, and signature. The header names the algorithm, typically RS256, and the type JWT. The payload holds claims such as sub, iss, aud, iat, exp, and maybe roles. The signature is a MAC or public-key signature over header.payload. An access token is not encrypted by default; JWS is not JWE, so anyone holding the token can read claims, which is why there are no passwords and no connection strings in the payload. Verification checks aud, iss, exp, and the signature with the Auth0 or JWKS public key; I never accept alg: none, and I do not paste keys. Opaque tokens need a server lookup; JWTs are locally verifiable and harder to revoke instantly without a denylist or a short TTL. Auth0 here is the skills authorization server that would publish JWKS, not a claimed Ylogx tenant.

Example. Payload { "sub": "user-id", "iss": "https://YOUR_TENANT/", "aud": "api://ylogx", "exp": 1710000000, "roles": ["tier2"] } signed RS256. NestJS loads JWKS and rejects a wrong aud. That YOUR_TENANT string is an illustration, not a production URL I will invent for Ylogx.

If they probe: JWE versus JWS; clock skew on exp; what belongs in claims versus what Postgres RLS still must enforce.

A server session stores an id-to-user mapping on the server, and the browser sends an HttpOnly Secure SameSite cookie. Revoke means delete the session; across ECS tasks you need sticky sessions or a shared store such as Redis. A JWT access token has no session row, so replicas scale without affinity; logout is drop the token plus a short exp, or a denylist. Cookies are auto-sent by the browser, so CSRF needs SameSite or a CSRF token; a Bearer header is not auto-sent by a random site. I pick from requirements: kill-session-now prefers a session or a short JWT plus denylist; NestJS on ECS without sticky sessions prefers JWT. Ylogx-shaped is JWT at the API plus RLS at the database. Bhavya’s Spring login can stay a session if they never asked for tokens. I still do not put secrets in a JWT payload, and I still execute SQL RAG as the user’s DB role.

Example. Session: Set-Cookie: sessionId=...; HttpOnly; Secure; SameSite=Lax and delete the row to revoke. JWT: Authorization: Bearer eyJ... with a short exp, NestJS verifies locally on any ECS task, Postgres still applies the three-tier RLS policy.

If they probe: refresh tokens in an HttpOnly cookie versus access in memory; CSRF versus Bearer; Redis session store versus a JWT denylist.

The access token authorizes API calls and should live minutes. The refresh token obtains a new access token, lives longer, and is not sent to resource APIs. The ID token is OIDC identity for the client, with sub and email, and it is not a substitute for RLS. I would keep refresh off the SPA localStorage if I can, using an HttpOnly cookie on the token endpoint; that is defensive and I will not give a theft recipe. Rotation issues a new refresh on each use and invalidates the old one. A hospital rotating-refresh story is off-resume; the mechanism is standard CS. A stolen access token’s blast radius is its TTL, and RLS still limits rows if the token’s role is scoped. I do not invent Auth0 refresh settings for Ylogx. NestJS should reject a refresh token sent as Bearer on a reports API.

Example. Access expires in minutes and goes to NestJS as Authorization: Bearer. Refresh is used only at /oauth/token with grant_type=refresh_token. The ID token tells the SPA who logged in; Postgres still filters by the three organizational tiers as role.

If they probe: rotation reuse detection at a high level; why an ID token is not AuthZ; whether RLS still applies after a refresh — yes, because a new access token still maps to the same DB role.

OAuth 2.0 authorization code plus PKCE is the must-know public-client flow. The client makes a high-entropy code_verifier and a code_challenge as BASE64URL of SHA-256 of the verifier. The user is redirected to the authorization server /authorize endpoint with client_id, redirect_uri, scope, state, code_challenge, and S256. The user logs in at Auth0; the app never sees the password. The callback returns code and state; the client checks state. The client POSTs to the token endpoint with code, verifier, client_id, and redirect_uri; the server proves the challenge matches. The response is an access token, optional refresh, and an OIDC id_token. Resource calls send Authorization: Bearer; NestJS validates the JWT and maps role; Postgres RLS filters. A confidential server app may add a client secret in addition to PKCE; an SPA cannot. Implicit grant with a token in the URL hash is legacy. Client-credentials is machine-to-machine and never for Ylogx end-user reports. Auth0 here is the skills authorization server, not a claimed Ylogx vendor bullet.

Example. SPA builds verifier and challenge → Auth0 /authorize → 302 with code and state → POST /oauth/token plus verifier → Bearer access to NestJS → SET ROLE or GUC → RLS returns only that tier’s rows.

If they probe: why not implicit; why a SPA has no client secret; state versus PKCE (CSRF on the redirect versus binding this client instance to this code); where refresh is stored.

Authentication is who you are: Auth0 or a password. Authorization is what you may do: RBAC on APIs. RLS is which rows exist for this role after authorization said run this query. App RBAC without RLS is a locked door and an unlocked warehouse window through JOINs. I do not use an LLM as authorization. At Ylogx both NestJS RBAC and Postgres RLS covered three organizational tiers as role, and SQL RAG ran as the user’s DB role. Plus 65% is the productivity number; it is not a license for the model to see every row. Auth0, if they bring it up, is a skills-list authorization server for AuthN, not the row filter.

Example. Auth0 says this is user X. NestJS says X may GET /reports. Postgres returns only X’s tier rows, even when the SQL RAG wrote a JOIN. A 200 with another tenant’s facts would be an AuthZ failure, not a successful query.

If they probe: ID token versus access token; FORCE ROW LEVEL SECURITY; GenAI as AuthZ — that is a should-not from the IE-asked card.

The client speaks TLS to the edge. The app in the VPC speaks HTTP. Certificates and private keys stay on the terminator, not in the Git repository. Nginx listen 443 ssl and proxy_pass to upstream is the skills sketch; an ALB HTTPS listener and CloudFront HTTPS do the same job. I list Nginx; the Ylogx path I can defend is CloudFront plus ALB. I will not say I configured Nginx for Ylogx unless confirmed off-resume. Sub-210 ms is CDN and cache on that path. Secrets for TLS are the cert and key on the edge, which is the same Earn Trust idea as not putting the database URL in the SPA.

Example. Browser to CloudFront over HTTPS; CloudFront to ALB; ALB to an ECS task over HTTP on a private port. The FastAPI or NestJS process never loads a PEM from the repo.

If they probe: cert files baked into the image; HTTP/2 at the edge; Nginx versus ALB for this intern — CloudFront and ALB are the bullets.

Secure means the cookie is sent only on HTTPS. HttpOnly means JavaScript cannot read it. SameSite=Lax or Strict reduces CSRF by limiting cross-site sends. These flags complement PKCE state on the OAuth redirect. I will not give bypass steps. For a Bhavya-style session login this is the cookie I would set. For Ylogx-shaped JWT APIs the access token is usually a Bearer header, not this cookie, unless they put refresh in an HttpOnly cookie. GiftedBooks can be a session or JWT on a per-user PDF API at sub-300 ms and 99.5%; it is still not three-tier warehouse RLS.

Example. Set-Cookie: sid=...; Secure; HttpOnly; SameSite=Lax; Path=/ after a successful Spring login. A refresh cookie, if used, is also HttpOnly and is sent only to the token endpoint, not to /reports.

If they probe: SameSite=None; Secure for a cross-site case; CSRF token with cookies; why refresh should not live in localStorage if you can avoid it — defensive only, no theft recipe.

SPA                         Auth0 (AS)                    NestJS API              Postgres
 |-- challenge, redirect -->|  login                      |                      |
 |<-- 302 ?code=&state= ----|                             |                      |
 |-- POST /token + verifier -->|                          |                      |
 |<-- access (+ refresh) ------|                          |                      |
 |-- Bearer access ---------------------------------------->| verify JWT         |
 |                                                         | SET ROLE / GUC ---->| RLS policies
 |                                                         |<-- rows for tier ---|

header    { "alg": "RS256", "typ": "JWT" }
payload   { "sub": "user-id", "iss": "https://YOUR_TENANT/", "aud": "api://ylogx",
            "exp": 1710000000, "roles": ["tier2"] }
signature RS256(base64url(header) + "." + base64url(payload), AS private key)

ALTER TABLE facts ENABLE ROW LEVEL SECURITY;
ALTER TABLE facts FORCE ROW LEVEL SECURITY; -- even table owner

-- Role per org tier (3 tiers on resume). Policy reads session GUC set by NestJS.
CREATE POLICY facts_isolation ON facts
  FOR ALL
  TO app_reader
  USING (tier_id = current_setting('app.tier_id')::int)
  WITH CHECK (tier_id = current_setting('app.tier_id')::int);

React → NestJS RBAC  --OK-->  SELECT * FROM facts JOIN x  --missed org filter-->  leak
React → NestJS RBAC  --OK-->  same SQL as DB role with RLS  -->  empty other tiers

interface Validator { void validate(LoginRequest req); }

final class LoginFacade {
    private final List<Validator> validators;
    private final AuthService auth;
    boolean login(LoginRequest req) {
        for (Validator v : validators) v.validate(req); // no if-else ladder
        return auth.authenticate(req); // hash compare via UserRepository
    }
}
// Controller.postLogin → facade.login

listen 443 ssl;
ssl_certificate     /etc/nginx/certs/fullchain.pem;   # paths only, no PEM paste
ssl_certificate_key /etc/nginx/certs/privkey.pem;
proxy_pass http://127.0.0.1:3000;  # NestJS/FastAPI