Approve Request

Approve, choosing the scope. Re-verifies the password.

Fresh authentication, not merely a session — and a password re-verify rather than a token-age test, because the access token carries iat and no auth_time and refresh mints fresh access tokens from the cookie indefinitely. now - iat < 5 min is therefore true for any SPA tab that has been open and refreshing, i.e. exactly the stale session the control exists to reject; a max-age framing would degrade silently to "has a session". POST /users/me/change-password is the primitive this codebase already has, and this is modelled on it.

The typed user_code is gone; approve_pairing asserts the row's address against this session instead. That assertion is not a formality and it lives in the service rather than here: /connect lists by address, so the request id is obtainable by anyone who can read the mailbox — and shared mailboxes (buchhaltung@, info@) are the norm among the customers this serves. A colleague opening a notice aimed at somebody else's account would otherwise sign in as themselves, re-verify their own password, pick their own company, and hand the requester a key to books nobody meant to grant.

full can never be granted here — refused by the schema and again below. One phished approval must not hand over everything; full-access stays browser-only.