Week 2 Worklog

Week 2 Objectives:

  • Backend: Integrate AWS Cognito authentication into Spring Security. Build the UserProfile module.
  • Frontend: Implement the complete authentication flow — from the Login screen through token storage and state management.
  • Establish secure token handling patterns that will be reused across the entire application.

Tasks to be carried out this week:

Day Task Start Date Completion Date Reference Material
2 - Study AWS Cognito User Pools concepts
  + User Pool configuration: password policies, app clients, PKCE
  + ID Token vs Access Token — difference and proper usage
  + Cognito JWT claims: sub, cognito:groups, token_use
01/13/2026 01/13/2026 https://docs.aws.amazon.com/cognito/
3 - Implement Spring Security JWT configuration
  + Add spring-security-oauth2-resource-server dependency
  + Configure SecurityConfig: stateless sessions, CSRF disabled, CORS enabled
  + Set Cognito issuer-uri in application.properties
  + Write custom OAuth2TokenValidator — reject tokens where token_use != "access"
01/14/2026 01/14/2026 https://docs.spring.io/spring-security/
3 - Implement role extraction from JWT
  + Read cognito:groups claim → convert to Spring ROLE_<GROUP> authorities
  + Configure @PreAuthorize("hasRole('ADMIN')") for admin endpoints
  + Define authorization rules: public endpoints, authenticated, admin-only
01/14/2026 01/14/2026
4 - Build UserProfile entity & repository
  + Fields: cognitoId (UNIQUE), email (UNIQUE), username, name, gender, birthdate, phoneNumber, picture, emailVerified
  + UserProfileRepository extends JpaRepository
01/15/2026 01/15/2026
4 - Build UserProfileService & UserProfileController
  + POST /user/sync — upsert profile from Cognito claims (IDOR-safe: cognitoSub from JWT sub)
  + GET /user/{id}, PUT /user/{id}, DELETE /user/{id}
01/15/2026 01/15/2026
5 - Build Frontend LoginScreen
  + Single “Sign in with AWS Cognito” button
  + Initiate PKCE flow via expo-auth-session + expo-web-browser
  + Handle redirect callback: exchange code → tokens
  + Decode ID Token with jwt-decode to extract user claims
01/16/2026 01/16/2026 https://docs.expo.dev/guides/authentication/
6 - Build authSlice (Redux) and token storage
  + State: isAuthenticated, user, token, refreshToken, hasCompletedOnboarding
  + Actions: login, logout, completeOnboarding, updateUserProfile
  + Persist tokens to expo-secure-store (mobile) / localStorage (web) via utils/storage.ts
- Wire Axios request interceptor: auto-attach Authorization: Bearer <token>
01/17/2026 01/17/2026

Week 2 Achievements:

  • Backend — Security:
    • Spring Security fully configured with AWS Cognito as JWT issuer.
    • Custom OAuth2TokenValidator blocks ID tokens — only Access Tokens accepted at the API layer.
    • Role-based access control works: ROLE_ADMIN group from Cognito grants admin privileges.
    • All security rules defined: public health check, authenticated user routes, admin-only /admin/** routes.
  • Backend — UserProfile module:
    • POST /user/sync correctly upserts user from Cognito JWT claims without IDOR vulnerability.
    • Full CRUD (GET, PUT, DELETE) on /user/{id} with proper authorization checks.
    • UserProfile entity persisted to PostgreSQL via JPA.
  • Frontend — Authentication:
    • LoginScreen renders correctly; tapping the button opens Cognito Hosted UI in browser.
    • PKCE code exchange works end-to-end — tokens returned and stored securely.
    • authSlice correctly toggles isAuthenticated; RootNavigator redirects to the right stack.
    • Axios interceptor auto-attaches Bearer token — subsequent API calls authenticated.

My Personal AWS Lab Notes (Individual Learning):

Lab 2 — IAM Role Setup for Daily Use

  • Created an IAM Role with appropriate policies and configured it for daily AWS tasks instead of relying on an IAM user with long-term access keys.
  • Learned: IAM Roles are preferred over IAM Users for EC2 instances and automated tasks because roles use temporary credentials (STS tokens) that auto-rotate, eliminating the risk of leaked static credentials. For human users doing daily work, a role is also better than hardcoding keys.

Lab 3 — Amazon VPC (Virtual Private Cloud)

  • Built a VPC from scratch with public and private subnets across multiple AZs.
  • Configured Route Tables: each route entry maps a destination CIDR to a target (IGW, NAT, local). Public subnets route 0.0.0.0/0 to the IGW; private subnets route it to the NAT Gateway.
  • Deployed an Internet Gateway (IGW): enables bidirectional internet traffic for resources in public subnets that have public IPs. AWS-managed, highly available, no maintenance needed.
  • Compared NAT Gateway vs NAT Instance:
    • NAT Gateway: AWS-managed, up to 100 Gbps, no maintenance, outbound-only, requires an Elastic IP in a public subnet. No port forwarding.
    • NAT Instance: User-managed EC2, single point of failure, flexible (supports port forwarding, can act as bastion host), billing based on instance type.
  • Learned Security Group vs NACL:
    • Security Groups attach to ENIs (Elastic Network Interfaces) — stateful, instance-level firewall.
    • NACLs attach to subnets — stateless, subnet-level firewall. Need inbound AND outbound rules.
    • Key insight: Route Tables and NACLs are subnet-level but are independent resources that subnets reference (not embedded inside subnets). Multiple subnets can share the same route table or NACL.
  • Configured VPC Endpoints: private access points to AWS services (like S3, SSM, ECR) without going over the internet.
    • Interface endpoints use ENIs with private IPs — need Security Groups to control access.
    • Gateway endpoints (S3, DynamoDB) do not use ENIs and route through the route table.
  • Fixed a tricky EC2 Instance Connect Endpoint misconfiguration: the EIC security group must allow outbound to the private subnet, AND the private instance security group must allow inbound from the EIC security group.
  • Set up a VPN connection to simulate hybrid on-prem networking: a second VPC acting as the on-prem side, using AWS Site-to-Site VPN to connect private IPs securely.

Lab 10 — Active Directory:

Used AWS Managed Microsoft AD (via AWS Directory Service) deployed into two private subnets to simulate an on-prem Windows domain controller for DNS and user management.

AWS Knowledge Summary (Concluded from Lab Notes):

  • Confirmed IAM roles with temporary credentials are safer than long-lived access keys for compute workloads and automation.
  • Internalized VPC routing design across public/private subnets with IGW and NAT to control internet exposure.
  • Distinguished Security Groups (stateful, ENI-level) from NACLs (stateless, subnet-level) for layered network security.
  • Learned how VPC endpoints and Site-to-Site VPN extend private connectivity to AWS services and hybrid networks.
  • Applied private-subnet deployment for managed directory services to support enterprise identity patterns securely.

Next Week Plan:

  • Backend: Build the common infrastructure layer — GlobalExceptionHandler, CorsConfig. Implement the GoalType module (first business module).
  • Frontend: Build navigation foundation — RootNavigator, AuthStack, MainTabs with custom tab bar, OnboardingStack.