Show HN: An OIDC Identity Provider where the LLM handles authentication logic

1 points by snakaya 2 months ago · 0 comments · 2 min read

I built a proof-of-concept OIDC Identity Provider where the authentication logic — including login page generation, credential validation, and authorization decisions — is delegated to an LLM via function calling.

  How it works:

  1. A user hits the /authorize endpoint (standard OIDC authorization code flow)
  2. Instead of rendering a hardcoded login page, the server asks the LLM to generate one
  3. When the user submits credentials, the LLM validates them using function calling (it calls back into the server's user store to check the password)
  4. If approved, the server issues a standard JWT and proceeds with the normal OIDC token exchange

  The LLM doesn't get the password directly or sign the JWT — it orchestrates the flow using tools/functions exposed to it, while the server handles the actual crypto.

  Stack: Deno + Oak, OpenAI API (gpt-5-mini default), in-memory storage, HS256 JWT, PKCE support (S256/plain).

  What's interesting:

  - The login UI is different every time (the LLM generates it fresh)
  - Authentication "logic" is emergent rather than coded — the LLM decides what steps to take
  - It actually works as a compliant OIDC IdP (discovery, authorization code, token exchange, userinfo)
  - It demonstrates both the potential and the absurdity of delegating security-critical decisions to an LLM

  What this is NOT: Production-ready. It's a thought experiment in code. Every login costs an API call, responses are slow, and there's no real security hardening. The point is to explore
  what happens when you let an LLM drive an authentication flow.

  Curious to hear what the HN community thinks. Is there any legitimate use case for AI-driven auth flows, or is this purely in "cursed demo" territory?

No comments yet.