Tinyauth is an authentication and authorization server. Prior to 5.0.3, the OIDC authorization endpoint allows users with a TOTP-pending session (password verified, TOTP not yet completed) to obtain authorization codes. An attacker who knows a user's password but not their TOTP secret can obtain valid OIDC tokens, completely bypassing the second factor. This vulnerability is fixed in 5.0.3.

Affected: Go: github.com/steveiliop56/tinyauth

### Summary

The OIDC authorization endpoint allows users with a TOTP-pending session (password verified, TOTP not yet completed) to obtain authorization codes. An attacker who knows a user's password but not their TOTP secret can obtain valid OIDC tokens, completely bypassing the second factor.

### Details

When a user with TOTP enabled logs in at `POST /api/user/login`, the server creates a session with `TotpPending: true` and returns a session cookie. The context middleware (`internal/middleware/context_middleware.go:56-66`) correctly sets `TotpPending: true` and does not set `IsLoggedIn` for these sessions.

However, the OIDC authorize handler (`internal/controller/oidc_controller.go:105-116`) only checks whether a user context exists via `utils.GetContext(c)`. It does not check `IsLoggedIn` or `TotpPending`. Since the context middleware populates a context for TOTP-pending sessions (with the username filled in), `GetContext` succeeds, and the handler proceeds to issue an authorization code at line 156 using the username from the incomplete session.

For comparison, the proxy controller (`internal/controller/proxy_controller.go:176-179`) correctly blocks TOTP-incomplete sessions by checking `IsBasicAuth && TotpEnabled` and setting `IsLoggedIn = false`. The OIDC authorize handler has no equivalent guard.

`StoreCode` at `internal/service/oidc_service.go:305` saves the code with the victim's `sub` claim. The attacker then exchanges this code at `POST /api/oidc/token` for…