Authentication and sessionsالمصادقة والجلسات

Authentication is a person proving they are who they say. Authorisation is being allowed to do one particular thing. A session is how long that proof stays valid before it is asked for again.

Every sensitive action needs separate answers about identity, permission, and how recently identity was proved.

Why ask me for a code when I am already logged in?

This genuinely irritates users. They proved who they were minutes ago and are asked again at the transfer.

Because logging in was not the answer to one question. It was the answer to three different ones that people routinely conflate.

The first: who are you? Answered once at signup, with identity and verification. The second: is it you right now? Answered at every login, with a password or a fingerprint. The third: do you intend this specific action? An entirely separate question.

Imagine someone picks up your unlocked phone. They have answered the second question effortlessly, because the session is already open. What stops them transferring your whole balance?

The third question does. Which is why a code or a fingerprint is demanded on a large transfer, on changing your mobile number, or on adding a new beneficiary. It is called step-up authentication: verification rises with the danger of the action rather than with the passage of time.

A session proves somebody logged in. It does not prove it is still them, and it does not prove they mean what they are doing now.

Separate the three questions

Authentication (المصادقة) proves who you are through evidence such as a password, known device, or biometric. It binds a session to an identity but does not define permissions.

Authorisation (التفويض) determines what that identity may do. Support may view transfer status without changing a beneficiary. A merchant manager may issue refunds without exporting every customer. The server must check permission on every request; hiding a button is not enforcement.

The third question is whether trust remains current. A customer may sign in before a phone is stolen. A password may change while an old session stays open. A valid session does not make every later action safe.

Build login from independent evidence

Passwords alone are insufficient for an app that moves money. Customers reuse them on breached sites or give them to phishing pages. Add independent evidence such as a security key or approval on a trusted device.

Do not make SMS the only protection in every case. Attackers can take over a SIM or persuade a carrier to move a number. Messages may support recovery or lower risk, while a large transfer requires stronger proof.

Store passwords with a slow purpose-built function such as Argon2 and a unique salt. Never reversibly encrypt, log, or reveal them to support staff.

A session is limited permission

A session begins after login and carries an identifier, creation and expiry times, and context. Keep sensitive customer data out of browser-readable tokens. Store the minimum and let the server revoke sessions.

For web apps, use protected cookies that page scripts cannot read, that travel only over encrypted connections, and that are restricted from cross-site sending.

Set duration according to risk. Viewing may last longer than permission to transfer. Long inactivity, a device change, or password reset should require fresh proof.

Step up at the risky moment

Step-up (التوثيق التصاعدي) authentication requests fresh evidence within an existing session. It belongs at beneficiary addition, phone changes, and unusual payments. Putting it on every screen trains customers to approve without reading.

Display the actual action: “Send SAR 8,000 to Khalid,” not “confirm activity.” Binding proof to details stops an attacker reusing approval for a different act.

Do not rely only on a channel that just changed. If a phone number was replaced one minute ago, a code to that number is not independent. Use a previously trusted device, delay, or human review according to value.

Apply least privilege

Do not grant an administrator role for one task. Give the smallest role for the shortest time. Exceptional access should require a recorded reason and approval, then expire automatically.

Separate initiation from approval for large payments. One treasury employee creates the payment and another manager approves it. One compromised account cannot move funds alone.

Review permissions regularly and immediately when staff move or leave. Many privilege failures come from old accounts retaining roles.

Treat recovery as high risk

“Forgot password” must not be weaker than login. Attackers may know email and identity details and pressure support staff. Recovery needs multiple signals, notification to old channels, and temporary limits on sensitive actions.

Train support not to bypass controls. Staff should never read a code to a caller or change a phone and permit an immediate transfer. Give them an escalation path.

Notify customers about new login, security changes, and beneficiaries. Include time, device, action, and a challenge route. Avoid making every alert look like a phishing login link.

Preserve investigation evidence

Record login success and failure, session creation and revocation, permission changes, and step-up reasons and outcomes. Link events by identifier without logging passwords, codes, or secrets.

Keep the trail beyond the reach of the employee being investigated. It should answer months later who entered, from which device, with what role, and who approved the action.

Test boundaries

Make a support account call an administrator endpoint. Try expired proof, a revoked session, and a request after password change. Add a beneficiary from a new device and attempt to send the whole balance.

Test the server, not only the interface. An attacker can call an API even when the app hides a refund button. The server must reject and record it.

Safety comes from combining all three questions. Prove identity, check permission for the exact action, and require fresh evidence when risk changes. None can substitute for another.