OAuth2/OIDC 실무 사고사례와 방지책

0. 주제 

• OAuth2/OIDC는 “로그인 기술”이 아니라 권한 위임 + 신원 확인 프로토콜 조합
• 실무 사고는 대부분 “구현 버그”가 아니라 설계/운영 실수에서 발생
• 자주 발생하는 사고 패턴을 원인 → 증상 → 탐지 → 방지책으로 정리

1. 정의

• OAuth2: “사용자 비밀번호를 서비스에 넘기지 않고도, 다른 서비스 자원을 접근할 수 있게” 권한을 위임하는 표준
• OIDC(OpenID Connect): OAuth2 위에 해당 사용자가 누구인지를 알려주는 인증 레이어를 얹은 것
• OAuth2 = 권한 위임(Authorization)
• OIDC = 신원 확인(Authentication)

2. 용어 정리

실무에서 혼동이 사고로 이어지는 경우가 많아서 용어를 정리함

• Resource Owner: 사용자
• Client: 우리 서비스(웹/앱)
• Authorization Server(AS): 인증 서버
• Resource Server(RS): API 서버
• Access Token: API 접근용
• Refresh Token: Access Token 재발급용
• ID Token(OIDC): “로그인한 사용자가 누구인지” (프로필/클레임)
• XSS: 공격 스크립트가 내 사이트 안에서 실행됨
• CSRF: 공격 사이트가 사용자 대신 요청만 보내게 함

• BFF: 프론트엔드(웹/모바일) 전용 백엔드 서버

• TTL: 유효시간 / 만료까지 남은 시간
• CSP: 브라우저에 거는 스크립트 실행 보안 규칙

3. “인증”과 “인가”를 섞으면 문제가 발생함

흔한 오해:

• JWT 토큰이 있으면 로그인 된 거니까 모든 API 요청이 통과되겠지?
• 인증 정보를 권한으로 착각
• Access Token 안에 userId 있으니 그걸 믿으면 되겠지?
• 권한 결정을 로그인 시점에 한 번만 하고 요청마다 안 해도 되겠지?

정답:

• ID Token은 “로그인 결과” 고, Access Token은 “API 접근 권한” 임

→ 로그인 시 Access / Refresh / ID Token 을 줌

• API는 반드시 Access Token만 신뢰해야 함

                                                                                                                                                                                                                  ⭐발표자 : 남상엽님