Skip to content

[P1] Reduce Apple login latency from repeated Apple provider round trips #323

Description

@jjoonleo

Problem

Apple login can be slow because the backend performs multiple blocking Apple provider calls during the request path.

Current flow in POST /oauth2/apple/login:

  • AppleLoginFilter.attemptAuthentication verifies the Apple identity token before DB lookup.
  • AppleLoginService.verifyIdentityToken fetches Apple public keys from https://appleid.apple.com/auth/keys on every login.
  • AppleLoginFilter.exchangeAppleRefreshToken calls AppleLoginService.getAppleAccessTokenAndRefreshToken before checking whether the Apple user already exists.
  • AppleLoginService.getAppleAccessTokenAndRefreshToken posts to https://appleid.apple.com/auth/token on every Apple login attempt.

This means even returning Apple users pay for at least one Apple public key fetch and one Apple token exchange before the local login response can complete.

Evidence

  • ontime-back/src/main/java/devkor/ontime_back/global/oauth/apple/AppleLoginFilter.java
    • lines around verifyIdentityToken(...)
    • line around exchangeAppleRefreshToken(...)
    • lines around userRepository.findBySocialTypeAndSocialId(...)
  • ontime-back/src/main/java/devkor/ontime_back/global/oauth/apple/AppleLoginService.java
    • verifyIdentityToken(...) calls Apple auth/keys through restTemplate.getForObject(...).
    • getAppleAccessTokenAndRefreshToken(...) calls Apple auth/token through restTemplate.exchange(...).
    • Apple provider RestTemplate is constructed directly with new RestTemplate().

Related broader hardening issue: #282 covers timeouts, retries, and failure handling for outbound OAuth provider calls. This issue focuses on Apple-login-specific latency reduction and request-path shape.

Required work

  • Cache Apple public keys/JWKS instead of fetching auth/keys for every login.
  • Respect Apple key rotation by refreshing cache on unknown kid or cache expiry.
  • Measure whether returning Apple users actually need auth/token exchange on every login.
  • If refresh-token update is not required for returning users, move the Apple token exchange after existing-user lookup or skip it when safe.
  • Add timing logs or metrics for Apple login stages:
    • identity token verification
    • Apple public key fetch/cache hit
    • Apple token exchange
    • DB lookup/register/login handling
  • Keep token values and authorization codes out of logs.

Acceptance criteria

  • Returning Apple-user login no longer fetches Apple public keys from the network on every request when a valid cached key is available.
  • Returning Apple-user login avoids unnecessary Apple auth/token exchange if product/security requirements allow it.
  • Apple key cache refresh is covered by tests, including unknown kid fallback.
  • Tests cover the login branch where Apple token exchange fails but verified identity login continues.
  • Logs or metrics make it clear which Apple-login stage is responsible when login latency spikes.
  • Any timeout/failure handling added here remains aligned with [P1] Add timeouts, retries, and failure handling for outbound OAuth provider calls #282.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:authAuthentication and authorizationarea:stabilityReliability and runtime stabilitypriority:P1High: should be resolved before production launchproduction-readinessProduction readiness audit itemtype:hardeningSecurity/stability hardening task

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions