MFA Attributes
MFA attributes are token fields that show how a user verified their second login factor. You set them up by mapping factor data from your identity provider into login claims. Security teams often check these fields before they let engineers open production databases or servers. When a role has broad permissions, a simple login check still leaves data at risk. Once the user logs in, they can run any command that the wide role allows. How mfa attributes work in login flows When a person logs in
Attributes: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
MFA attributes are token fields that show how a user verified their second login factor. You set them up by mapping factor data from your identity provider into login claims. Security teams often check these fields before they let engineers open production databases or servers. When a role has broad permissions, a simple login check still leaves data at risk. Once the user logs in, they can run any command that the wide role allows.
How mfa attributes work in login flows
When a person logs in, the identity provider checks their password and second factor. That second factor might be a hardware key, a phone push, or a time code. The provider then builds a token and writes mfa attributes inside the token payload. These fields record the factor type, the login time, and the assurance level.
Downstream apps read this token to decide if the user can enter the system. You can write a rule that asks for a hardware key before granting a role. If the token only shows an SMS code, the target app blocks the login attempt. Teams also check the timestamp field to force a fresh check before high-risk work. If the last factor check happened hours ago, the system asks for a new prompt.
What native factor checks solve and what they miss
Native factor checks do a great job of blocking stolen passwords at the front door. They prove that the right person is sitting at the keyboard when the session starts. They also let you demand phishing-resistant keys for your most sensitive production roles. This stops many basic account takeover attacks before an attacker reaches your private network.
Still, login claims only govern the moment a user starts a new session. Once the database or server accepts the token, the factor check is over. Native mfa attributes cannot see which SQL queries or shell commands run inside that session. If an engineer holds an admin role, every query runs with full admin power. A user who passed a hardware key check can still drop a table by mistake. They can also run a big select query that returns thousands of customer card numbers. Standard token claims also do not apply to shared database accounts with static passwords.
Attributes: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Designing factor rules for database and server work
Start by listing which systems hold customer data like emails, phone numbers, or national IDs. Set your identity provider to send clear factor claims in every login token. Write role rules that require strong hardware keys for any production system login. Keep the allowed session age short so old tokens cannot open new sessions later.
Next, look at what happens after the user passes the initial login prompt. Separate read roles from write roles so a normal login cannot change live data. For risky updates, require a peer review on the exact command before it runs. Pair strong login checks with data masking that rewrites emails and card numbers in results. This keeps sensitive records safe even after an engineer completes a valid multi-factor login.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What information do MFA claims carry in a token?
They usually carry the factor method used, the exact login time, and a trust level. Target systems read these values to check if the login meets your security rules.
Can factor claims require a fresh prompt for one specific SQL query?
No, standard identity tokens only check factors when the user logs in or switches roles. They cannot inspect individual SQL statements or pause a single query for approval.
What happens if an identity provider omits factor fields from the token?
If a rule requires those fields, the target system will reject the login right away. You must map the factor claims in your identity provider settings so downstream rules work.