이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 구글 로그인을 연동할 때 OAuth2 흐름을 처음 직접 구현했습니다. Authorization Code Flow를 따라가면서 액세스 토큰과 리프레시 토큰의 역할 차이를 실제로 이해했습니다. OIDC는 OAuth2 위에 사용자 신원 확인 레이어를 얹은 것으로, ID 토큰을 통해 인증 정보를 전달한다는 차이가 있습니다. 구현 중 state 파라미터로 CSRF를 방어하는 부분에서 왜 이 절차가 있는지를 처음 이해했습니다. 아직 대규모 인증 시스템을 설계한 경험은 없지만, 프로토콜의 흐름과 보안 목적을 이해하고 있어서 실무에 빠르게 연결할 수 있다고 생각합니다. 이 경험 이후 인증 흐름을 처음부터 직접 구현하는 것이 가장 빠른 이해 방법이라는 걸 배웠습니다.
보안 프로토콜은 코드로 먼저 이해하는 게 개념 학습보다 효과적이었습니다.
OAuth2 구현에서 단순 로그인 연동보다 어려웠던 부분은 액세스 토큰이 만료됐을 때 자동으로 갱신하는 흐름이었습니다. 처음에는 만료 에러가 발생하면 사용자를 로그인 페이지로 리다이렉트했는데, 세션 유지가 짧아서 사용성이 떨어지는 문제가 있었습니다. 리프레시 토큰을 활용해서 액세스 토큰이 만료되기 직전에 자동 갱신하는 로직을 추가했습니다. 구현에서 어려웠던 점은 여러 요청이 동시에 만료를 감지했을 때 갱신 요청이 중복으로 발생하는 경쟁 조건이었습니다. 갱신 중 상태를 플래그로 관리해서 하나의 갱신 요청만 진행하고 나머지는 그것이 완료될 때까지 기다리는 방식으로 해결했습니다.
인증 흐름은 정상 케이스보다 만료·갱신·에러 케이스를 어떻게 처리하느냐가 품질을 결정한다는 것이 이 경험의 핵심이었습니다.
OAuth2에서 PKCE(Proof Key for Code Exchange) 확장을 공부했는데, 단일 페이지 앱(SPA)에서 클라이언트 시크릿을 안전하게 보관할 수 없는 문제를 해결하는 방법이었습니다. 브라우저에서 동작하는 앱은 소스코드가 노출되기 때문에 시크릿을 코드에 포함시키면 노출 위험이 있습니다. PKCE는 임시 코드 검증값을 생성해서 인가 코드를 가로채더라도 액세스 토큰을 얻을 수 없게 만드는 방식입니다. 사이드 프로젝트에서 이 방식을 적용했을 때, Authorization Code Flow에 PKCE를 얹는 것이 SPA의 표준 인증 패턴이라는 것을 이해했습니다. OIDC와의 차이는 OIDC가 인증(누구인가)을 다루고 OAuth2가 인가(무엇을 할 수 있는가)를 다룬다는 것이고, 실제 구현에서는 두 가지가 함께 쓰이는 경우가 많습니다.
보안 프로토콜은 왜 이런 절차가 있는지를 이해해야 올바르게 구현할 수 있다는 것이 이 공부에서 배운 것입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 보안 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.