Authentication (AuthN) is the process of verifying a user's identity - confirming that someone is who they claim to be. It answers the question "Who are you?"
Authorization (AuthZ) is the process of determining what an authenticated user is allowed to do - controlling access to resources and actions based on permissions, roles, or policies. It answers the question "What can you do?"
When you use a mobile banking app:
Authentication always happens first. You cannot authorize someone without first knowing who they are.
Financial regulations (PSD2, PCI DSS, SOC 2) mandate strict identity verification and access controls.
Strong authentication prevents unauthorized access while proper authorization limits damage from compromised accounts.
Ensures customers can only access their own financial data and authorized account holders can perform appropriate actions.
Prevents any single person from completing critical financial transactions alone, reducing insider fraud risk.
Proper security measures build confidence in your financial platform.
Context-aware authorization helps identify and block suspicious activities based on transaction patterns, amounts, and environmental factors.
┌─────────────────────────────────────────┐
│ AUTHENTICATION FLOW │
├─────────────────────────────────────────┤
│ │
│ User Attempts Access │
│ │ │
│ ▼ │
│ Provides Credentials │
│ (PIN, Password, Biometric) │
│ │ │
│ ▼ │
│ System Validates Credentials │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Valid? │───▶│ Grant Entry │ │
│ │ YES │ │ (AuthN ✓) │ │
│ └──────────────┘ └──────────────┘ │
│ │ │
│ │ NO │
│ ▼ │
│ ┌──────────────┐ │
│ │ Deny Access │ │
│ │ (AuthN ✗) │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────┘
What happens:
┌─────────────────────────────────────────┐
│ AUTHORIZATION FLOW │
├─────────────────────────────────────────┤
│ │
│ User Already Authenticated ✓ │
│ │ │
│ ▼ │
│ Requests Specific Action │
│ (Transfer $10K, View Reports) │
│ │ │
│ ▼ │
│ System Checks Permissions │
│ (Role, Limits, Policies) │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Authorized? │───▶│ Allow Action │ │
│ │ YES │ │ (AuthZ ✓) │ │
│ └──────────────┘ └──────────────┘ │
│ │ │
│ │ NO │
│ ▼ │
│ ┌──────────────┐ │
│ │ Deny Action │ │
│ │ (AuthZ ✗) │ │
│ └──────────────┘ │
│ │
└─────────────────────────────────────────┘
What happens:
Traditional knowledge-based authentication.
User Input: PIN 4268
↓
Hash: SHA-256
↓
Compare with stored hash
↓
Match? → Authentication Success
Use cases:
Required by regulations like PSD2 and PCI DSS.
Layer 1: Something You Know
└─ Password/PIN
↓
Layer 2: Something You Have
└─ SMS Code, Auth App, Hardware Token
↓
Layer 3: Something You Are (optional)
└─ Fingerprint, Face ID
↓
All Layers Valid? → Grant Access
Use cases:
Using physical characteristics for identity verification.
Physical devices for high-security scenarios.
Examples:
For third-party integrations and open banking.
Step 1: User redirected to bank login
Step 2: User authenticates with bank
Step 3: Bank issues access token
Step 4: Third-party app uses token for API access
Use cases:
Permissions granted based on user roles.
ROLE HIERARCHY
═══════════════
Admin (Full Access)
│
├─── Account Manager
│ ├─ View all customer accounts
│ ├─ Process transactions up to $50K
│ └─ Generate reports
│
├─── Compliance Officer
│ ├─ View audit logs
│ ├─ Review flagged transactions
│ └─ Access regulatory reports
│
└─── Customer Service Rep
├─ View customer profiles
├─ Reset passwords
└─ Process transactions up to $5K
Use cases:
Dynamic permissions based on multiple attributes.
PERMISSION DECISION TREE
════════════════════════
User Attributes:
- Role: Senior Trader
- Department: Equities
- Clearance: Level 3
- Location: New York Office
Resource Attributes:
- Type: Trading Account
- Region: US Markets
- Risk Level: High
Environmental Attributes:
- Time: Market Hours
- Network: Corporate VPN
- Device: Company-issued
↓
All Conditions Met? → ALLOW
Any Condition Failed? → DENY
Use cases:
Permissions based on relationships between entities.
RELATIONSHIP MATRIX
═══════════════════
Customer A
│
├─ Account Owner → Full Access
│
├─ Joint Account Holder → Limited Access
│ └─ Can view, can transact up to limit
│
├─ Authorized Signer → Specific Access
│ └─ Can approve wires, cannot close account
│
└─ Read-Only Viewer → Minimal Access
└─ Can view statements only
Use cases:
Specific permissions for individual users or groups.
Example:
Account #1234567890:
- john.doe@company.com: OWNER (all permissions)
- jane.smith@company.com: VIEWER (read-only)
- accounting@company.com: TRANSACTION (up to $10K)
Custom rules combining multiple factors.
Example Policy:
IF user.role = "trader"
AND transaction.amount > $100,000
AND time NOT IN market_hours
THEN require_additional_approval
Let's examine AuthN and AuthZ in a comprehensive banking scenario.
┌─────────────────────────────────────┐
│ USER: Sarah Chen │
│ DEVICE: iPhone 14 (registered) │
│ LOCATION: Shirakalu │
└─────────────────────────────────────┘
↓
┌─────────────────────────────────────┐
│ AUTHENTICATION STEPS │
├─────────────────────────────────────┤
│ 1. Face ID Scan │
│ └─ Biometric verified ✓ │
│ │
│ 2. Device Fingerprint Check │
│ └─ Registered device ✓ │
│ │
│ 3. Session Token Generation │
│ └─ Token: abc123xyz... │
│ │
│ 4. Risk Assessment │
│ └─ Known location ✓ │
│ └─ Normal usage time ✓ │
│ │
│ → AUTHENTICATION SUCCESSFUL │
└─────────────────────────────────────┘
Scenario A: Viewing Account Balance
Action: View Checking Account
↓
Authorization Check:
├─ User Role: Account Owner ✓
├─ Account Relationship: Primary ✓
├─ Account Status: Active ✓
└─ Privacy Settings: Allowed ✓
↓
Result: ALLOW → Display Balance
Scenario B: Transfer Exceeding Limit
Action: Transfer $15,000 to External Account
↓
Authorization Checks:
├─ Daily Transfer Limit: $10,000 ✗
│ └─ Transaction exceeds limit
│
└─ Result: DENY
└─ Error: "Transaction exceeds daily limit"
Scenario C: High-Value Transfer with Step-Up Authentication
Action: Transfer $50,000 (within account limits)
↓
Authorization Check:
├─ Amount > $25,000 → High Risk
├─ Requires Step-Up Auth
│
↓
Additional Authentication Required:
├─ SMS Code sent
├─ User enters code
└─ Code verified ✓
↓
Authorization Re-check:
├─ Enhanced authentication ✓
├─ Transfer limit: $100,000 ✓
├─ Account balance sufficient ✓
└─ Anti-fraud checks passed ✓
↓
Result: ALLOW → Execute Transfer
| User Role | View Balance | Domestic Transfer | International Transfer | Close Account | Download Tax Docs | Manage Users |
|---|---|---|---|---|---|---|
| Primary Account Holder | ✓ | ✓ (up to $100K/day) | ✓ (with step-up auth) | ✓ | ✓ | ✓ |
| Joint Account Holder | ✓ | ✓ (up to $100K/day) | ✓ (with step-up auth) | ✗ (requires primary) | ✓ | ✗ |
| Authorized User | ✓ | ✓ (up to $5K/day) | ✗ | ✗ | ✗ | ✗ |
| Read-Only Delegate | ✓ | ✗ | ✗ | ✗ | ✓ | ✗ |
| Minor (Under 18) | ✓ | ✓ (up to $500/day) | ✗ | ✗ | ✗ | ✗ |
┌────────────────────────────────────────────────────┐
│ LOAN APPROVAL AUTHORIZATION MATRIX │
├────────────────────────────────────────────────────┤
│ │
│ Loan Amount: $250,000 │
│ Type: Commercial Real Estate │
│ Applicant Risk Score: Medium │
│ │
├────────────────────────────────────────────────────┤
│ │
│ Level 1: Loan Officer │
│ ├─ Can review application ✓ │
│ ├─ Can approve up to $100K ✗ │
│ └─ Must escalate to Level 2 │
│ │
│ Level 2: Senior Underwriter │
│ ├─ Can approve up to $500K ✓ │
│ ├─ Reviews credit analysis ✓ │
│ ├─ Checks compliance flags │
│ │ ├─ AML screening ✓ │
│ │ ├─ Sanctions list ✓ │
│ │ └─ Risk assessment ✓ │
│ └─ Requires co-approval for commercial │
│ │
│ Level 3: Compliance Officer (Co-Approval) │
│ ├─ Reviews regulatory compliance ✓ │
│ ├─ Checks documentation completeness ✓ │
│ └─ Provides compliance sign-off ✓ │
│ │
│ Final Decision: APPROVED │
│ (Requires 2 of 3 signatures) │
│ │
└────────────────────────────────────────────────────┘
PRINCIPLE: No single person can complete critical transactions
Transaction: Wire Transfer $1M+
═══════════════════════════════
Step 1: Initiator (Trader)
└─ Creates transfer request
└─ Cannot approve own requests
Step 2: First Approver (Team Lead)
└─ Reviews and approves
└─ Cannot be same as initiator
Step 3: Second Approver (Risk Manager)
└─ Final authorization
└─ Cannot be initiator or first approver
Step 4: Execution (Operations)
└─ Processes approved transfer
└─ Cannot initiate, approve, or modify
All 4 roles required → Complete transaction
Financial systems use dynamic authorization based on multiple factors:
AUTHORIZATION DECISION FACTORS
══════════════════════════════
User Context:
├─ Role: Premium Customer
├─ Account Age: 5 years
├─ Credit Score: 780
└─ Relationship Manager: Yes
Transaction Context:
├─ Amount: $75,000
├─ Type: Wire Transfer
├─ Destination: New Payee
└─ Frequency: First time
Environmental Context:
├─ Time: 2:00 AM (unusual)
├─ Location: Foreign IP address
├─ Device: Unrecognized
└─ Network: Public WiFi
Risk Score Calculation:
├─ User Trust: +20 points
├─ Transaction Risk: -30 points
├─ Environmental Risk: -40 points
└─ Total Score: -50 (HIGH RISK)
Decision: REQUIRE ADDITIONAL VERIFICATION
├─ Send push notification
├─ Require phone call verification
└─ Implement 24-hour hold
Real-world example: A customer with a 10-year account history transferring $5,000 from their home network during business hours might not trigger additional checks. The same customer transferring $50,000 at 3 AM from a foreign country would require step-up authentication.
How AuthN and AuthZ work together in API-driven financial services:
┌────────────────────────────────────────────────┐
│ OPEN BANKING: THIRD-PARTY APP ACCESS │
└────────────────────────────────────────────────┘
Step 1: User wants to use budgeting app (Mint)
└─ App needs read access to bank account
Step 2: AUTHENTICATION
┌─────────────────────────────┐
│ Redirect to Bank Login Page │
│ ├─ User: john@email.com │
│ ├─ Password: ******** │
│ └─ 2FA Code: 123456 │
└─────────────────────────────┘
↓
Bank authenticates user ✓
Step 3: AUTHORIZATION (Consent)
┌──────────────────────────────────┐
│ Mint App requests permission: │
│ │
│ ☑ Read account balances │
│ ☑ Read transaction history │
│ ☐ Initiate payments │
│ │
│ [ Approve ] [ Deny ] │
└──────────────────────────────────┘
↓
User approves ✓
Step 4: TOKEN GENERATION
┌──────────────────────────────┐
│ Access Token: eyJhbGc... │
│ Scope: read:accounts │
│ Expires: 3600 seconds │
│ Refresh Token: dGVzdC... │
└──────────────────────────────┘
Step 5: API ACCESS
Mint uses token to:
├─ GET /accounts → ALLOWED ✓
├─ GET /transactions → ALLOWED ✓
└─ POST /payment → DENIED ✗ (not authorized)
Key points:
| Aspect | Authentication (AuthN) | Authorization (AuthZ) |
|---|---|---|
| Purpose | Verify identity | Control access |
| Question | "Who are you?" | "What can you do?" |
| When | First (at login) | After authentication |
| Methods | Password, MFA, biometrics, OAuth | RBAC, ABAC, ReBAC, policies |
| Result | Logged in / Denied access | Action allowed / Action denied |
| Frequency | Once per session | Every action/resource request |
| Changes | Rarely (new auth methods) | Frequently (role/permission changes) |
| Failure Impact | Cannot access system at all | Cannot perform specific action |
| Stored As | Credentials, tokens | Roles, permissions, policies |
| Compliance | KYC, identity verification | Segregation of duties, least privilege |
Complex authorization based on multiple factors:
TRANSACTION AUTHORIZATION CALCULATION
═══════════════════════════════════════
Account Type | Standard | Premium | Business
Daily Limit | $5,000 | $25,000 | $100,000
+
User Verification | Basic | Enhanced | Full
Additional Limit | +$0 | +$10,000 | +$50,000
+
Transfer Type | Internal | Domestic | International
Risk Multiplier | 1.0x | 0.8x | 0.5x
+
Time of Day | Business Hours | After Hours
Additional Factor | 1.0x | 0.7x
EXAMPLE CALCULATION:
═══════════════════
Premium Account: $25,000
Enhanced Verification: +$10,000
= $35,000 base limit
International Transfer: ×0.5
= $17,500
After Hours (9 PM): ×0.7
= $12,250 final limit
Problem:
// Authorization checks spread across codebase
// In controller
if (user.role !== 'admin') return 403;
// In service layer
if (amount > user.dailyLimit) throw Error();
// In middleware
if (!user.permissions.includes('transfer')) next(error);
// In database query
WHERE account.owner_id = current_user.id
// ❌ Inconsistent, hard to maintain, easy to miss
Solution:
// Centralized authorization service
class AuthorizationService {
canTransfer(user, account, amount) {
return this.checkAll([
this.hasRole(user, ['customer', 'admin']),
this.ownsAccount(user, account),
this.withinLimit(user, amount),
this.passesRiskCheck(user, amount),
this.hasPermission(user, 'transfer')
]);
}
canApprove(user, transaction) {
return this.checkAll([
this.hasRole(user, ['manager', 'admin']),
this.notInitiator(user, transaction),
this.hasApprovalAuthority(user, transaction.amount)
]);
}
}
// ✓ Single source of truth
// ✓ Easy to audit
// ✓ Consistent enforcement
Problem: Mixing session-based and token-based auth creates inconsistencies.
Solution:
SESSION-BASED (Traditional Web Apps):
├─ Server stores session
├─ Cookie sent with each request
└─ Good for: Web portals, admin dashboards
TOKEN-BASED (Modern APIs):
├─ Stateless JWT tokens
├─ Token sent in Authorization header
└─ Good for: Mobile apps, microservices, SPAs
HYBRID APPROACH:
├─ Use sessions for web interface
├─ Use tokens for API/mobile
└─ Separate auth flows, same authorization engine
Problem: Users accumulate permissions over time, violating least privilege.
Solution:
REGULAR ACCESS REVIEWS
══════════════════════
Quarterly Review:
├─ List all user permissions
├─ Verify business justification
├─ Remove unnecessary access
└─ Document changes
Automated Checks:
├─ Flag permissions unused >90 days
├─ Alert on privilege escalation
├─ Require re-approval annually
└─ Revoke access on role change
SECURITY LAYERS
═══════════════
Layer 1: Network Security
└─ Firewall, DDoS protection, VPN
Layer 2: Authentication
└─ MFA, biometrics, device fingerprinting
Layer 3: Authorization
└─ RBAC, transaction limits, approval workflows
Layer 4: Data Encryption
└─ TLS, encryption at rest, tokenization
Layer 5: Monitoring
└─ Fraud detection, audit logs, alerts
Layer 6: Compliance
└─ PCI DSS, SOC 2, regulatory requirements
Grant only the minimum permissions necessary.
EXAMPLE: Customer Service Representative
═════════════════════════════════════════
✓ Can view customer profiles
✓ Can reset passwords
✓ Can process refunds up to $500
✓ Can view transaction history
✗ Cannot view full card numbers
✗ Cannot approve large transfers
✗ Cannot modify account balances
✗ Cannot access admin functions
Review Period: Every 6 months
Temporary Elevation: Requires manager approval + audit
Require additional authentication for sensitive operations.
STEP-UP AUTH TRIGGERS
═════════════════════
Low Risk (No step-up needed):
├─ View balance
├─ View transaction history
└─ Small transfers (<$500)
Medium Risk (SMS code):
├─ Transfers $500-$10,000
├─ Add new beneficiary
└─ Change contact info
High Risk (Multiple factors):
├─ Transfers >$10,000
├─ Wire transfers
├─ Account closure
└─ Access from new device/location
Log all authentication and authorization events.
AUDIT LOG ENTRY
═══════════════
Timestamp: 2025-12-12T14:23:45Z
Event: TRANSFER_INITIATED
User: sarah.chen@bank.com (ID: U12345)
Action: TRANSFER
Resource: Account #1234567890
Amount: $50,000.00
Destination: External Account #9876543210
Status: PENDING_APPROVAL
IP: 192.168.1.100
Device: iPhone 14 (ID: D-ABC123)
Location: Shirakalu (37.7749°N, 122.4194°W)
Risk Score: Medium (65/100)
Auth Method: Face ID + SMS
Approvers Required: 2
Next Action: Awaiting manager approval
Prevent brute force attacks and abuse.
RATE LIMITS
═══════════
Login Attempts:
├─ 5 failed attempts → 5 minute lockout
├─ 10 failed attempts → 30 minute lockout
└─ 15 failed attempts → Account locked, call required
API Requests:
├─ 100 requests/minute per user
├─ 1,000 requests/hour per user
└─ 10,000 requests/day per user
Transactions:
├─ Max 10 transfers per hour
├─ Max 50 transfers per day
└─ Velocity checks for unusual patterns
STRONG CUSTOMER AUTHENTICATION (SCA)
════════════════════════════════════
Required For:
├─ Online payments
├─ Account access via third parties
├─ Remote electronic transactions
└─ High-risk transactions
Two of Three Factors Required:
├─ Knowledge: Password, PIN
├─ Possession: Phone, token, card
└─ Inherence: Fingerprint, face, voice
Exemptions:
├─ Low-value transactions (<€30)
├─ Trusted beneficiaries
├─ Recurring payments (first payment requires SCA)
├─ Low-risk transactions (TRA - Transaction Risk Analysis)
└─ Contactless payments (<€50)
ACCESS CONTROL REQUIREMENTS
═══════════════════════════
Requirement 7: Restrict access to cardholder data
├─ Need-to-know basis only
├─ Assign unique ID to each person
├─ Deny all access by default
└─ Document approval for all access
Requirement 8: Identify and authenticate access
├─ Unique user IDs (no shared accounts)
├─ Multi-factor authentication for remote access
├─ Password complexity requirements
├─ Account lockout after failed attempts
└─ Password history (no reuse of last 4)
Requirement 10: Track and monitor all access
├─ Log all access to cardholder data
├─ Log all actions by privileged users
├─ Retain audit logs for 1 year (3 months online)
└─ Review logs daily
ACCESS CONTROL CRITERIA
═══════════════════════
CC6.1: Logical Access Controls
├─ Authentication mechanisms
├─ Authorization rules
└─ Access review processes
CC6.2: Prior to Issuing Credentials
├─ Approval workflows
├─ Identity verification
└─ Background checks
CC6.3: Removal of Access
├─ Timely deprovisioning
├─ Automated termination processes
└─ Access reviews after role changes
□ User provides credentials
□ System validates credentials
□ Generate session/token
□ Set appropriate expiration
□ Return authentication result
□ Log authentication attempt
□ Verify user is authenticated
□ User requests action/resource
□ Check user permissions
□ Evaluate context (time, location, risk)
□ Apply business rules
□ Allow or deny action
□ Log authorization decision
// Authentication
await auth.login(email, password);
await auth.verify2FA(userId, code);
await auth.validateToken(token);
await auth.logout(token);
// Authorization
await authZ.hasPermission(user, 'action');
await authZ.hasRole(user, ['admin', 'manager']);
await authZ.canAccess(user, resource);
await authZ.checkLimit(user, amount);
| When | Authentication | Authorization |
|---|---|---|
| Happens | First, at entry point | After authentication, for every action |
| Verifies | User identity | User permissions |
| Results | Logged in or denied access | Action allowed or denied |
| Changes | Rarely (new auth methods) | Frequently (role/permission updates) |
| Failure | Cannot access system | Cannot perform specific action |
| Implementation | Central auth service | Distributed permission checks |
| Token/Session | Creates session/token | Validates against token claims |
| User Experience | Login screen, MFA prompts | Hidden (seamless) or error messages |
| Logging Priority | Failed attempts critical | All actions should be logged |
| Compliance Focus | Identity verification (KYC) | Segregation of duties, least privilege |
# Issue: User cannot log in
Check:
├─ Credentials correct?
├─ Account locked?
├─ Password expired?
├─ MFA device accessible?
└─ Network connectivity?
# Issue: Session expires too quickly
Solution:
├─ Adjust token expiration time
├─ Implement refresh tokens
└─ Use sliding session windows
# Issue: User cannot perform allowed action
Check:
├─ Role assignment correct?
├─ Permissions up to date?
├─ Resource ownership verified?
├─ Transaction limits current?
└─ Check audit logs for details
# Issue: Authorization too permissive
Solution:
├─ Review all role permissions
├─ Implement principle of least privilege
├─ Add approval workflows
└─ Enable audit logging
# Issue: Slow authorization checks
Optimize:
├─ Cache permission lookups
├─ Use indexed database queries
├─ Implement permission hierarchies
└─ Batch authorization checks
# Issue: Token validation overhead
Solution:
├─ Use JWT for stateless auth
├─ Cache public keys
└─ Implement token blacklist efficiently
Authentication and Authorization are the twin pillars of security. Understanding and correctly implementing both is critical for:
In financial technology, security breaches can result in:
By properly implementing authentication to verify identity and authorization to control access, you create a robust security foundation that protects your customers, your organization, and the integrity of a system.
Remember: Authentication proves who you are. Authorization determines what you can do. Both must work flawlessly together to keep your systems/customers safe and secure.
RFC 6749 - OAuth 2.0 Authorization Framework
RFC 6749 outlines the core roles, token types, grant flows (Authorization Code, Implicit, Resource Owner Password, Client Credentials), security considerations, and extensibility mechanisms used widely across modern identity and access management systems.
TOTP Authentication