[OAuth] 인증/디바이스 토큰 탈취 취약점 다시 보기

 

공격자 관점과 취약점 진단 관점에서 다시 보기

 

Summary

최근 OAuth 계열 공격은 더 이상 단순한 계정 탈취 문제로 보기 어렵다.
실제 공격자의 목표는 아이디·비밀번호 자체보다, 사용자 동의와 권한 위임 구조를 이용해 장기적인 API 접근권한을 확보하는 것에 가깝다. 그래서 방어도 인증 강도만 높인다고 해결되지 않으며, 결국 핵심은 누가 어떤 애플리케이션에 어떤 범위의 권한을 넘겼는지 검증하고 통제하는 체계에 있다.

 

1. 반복되는 주제, 하지만 다시 보게 된 배경

 

취약점 진단 업무를 하다 보면, 한동안은 인증 우회나 세션 하이재킹처럼 비교적 익숙한 공격 시나리오에 시선이 머무르기 쉽습니다. 저 역시 실무 초반에는 “계정을 직접 탈취가능한가”, “로그인 계정의 식별이 가능한가” 같은 포인트에 집중하는 편이었습니다. 그런데 최근 몇 년간 OAuth 관련 사례를 계속 따라가면서 생각이 많이 바뀌었습니다.

OAuth 기반 공격은 겉으로 보기에는 정상 인증 흐름을 따르는 것처럼 보입니다. 사용자는 실제 로그인 페이지를 보고, 실제 동의 화면을 보고, 실제 코드 입력 절차를 수행합니다. 이 때문에 보안 담당자나 진단가가 피상적으로 보면 “사용자가 속았다” 정도로 정리해버리기 쉽습니다. 하지만 조금만 깊게 들여다보면 문제의 본질은 단순 피싱이 아니라, 정상적인 권한 위임 절차가 공격자에게 유리하게 악용될 수 있도록 설계·운영되고 있다는 점에 있습니다.

작년부터 2026년 초까지 공개된 여러 사례를 보면 흐름은 크게 두 갈래로 정리됩니다.

첫째는 OAuth 리디렉션 남용입니다. 정상 IDP(예: Entra ID, Google Workspace)의 리디렉션 흐름을 교묘하게 이용해 사용자를 공격자 측 컨트롤 구간으로 유도하고, 그 과정에서 인증 또는 동의 단계를 은닉하거나 왜곡하는 방식입니다.

둘째는 디바이스 코드 피싱(Device Code Phishing) 입니다. Device Authorization Grant 자체는 합법적인 인증 절차이지만, 사용자가 코드를 입력하게 만드는 사회공학적 흐름이 결합되면 공격자는 비밀번호를 직접 몰라도 권한 있는 토큰 확보를 노릴 수 있습니다.

이 두 유형은 세부 기법은 다르지만, 공격자의 목표는 상당히 유사합니다. 결국 공격자가 원하는 것은 “로그인 성공”이 아니라 API 호출권한과 지속성입니다. 즉, 비밀번호를 바꾸거나 MFA를 다시 설정하지 않아도 일정 기간 자산 접근을 유지할 수 있는 상태가 더 가치 있습니다. 실무에서는 이 점이 매우 중요합니다. 많은 조직이 여전히 인증 실패와 이상 로그인에만 시선을 두는데, 실제 피해는 그 이후의 동의된 권한과 토큰 지속성에서 커지는 경우가 많기 때문입니다.

 

2. 공격자 관점에서의 주요사항

 

이 유형을 공격자 관점으로 다시 분석해보면, 가장 먼저 보이는 것은 완전한 계정 지배보다 권한 유지가 더 중요해졌다는 점입니다.

보통 사용자는 의심스러운 로그인 알림이나 MFA 알림에는 어느 정도 민감하게 반응합니다. 하지만 이미 특정 애플리케이션에 고권한 동의를 해버렸거나, 디바이스 코드 절차를 통해 장기 토큰 발급이 가능한 상태라면, 비밀번호를 바꾼 뒤에도 공격 흔적이 바로 사라지지 않을 수 있습니다. 공격자는 계정 그 자체를 소유하지 않더라도, 실질적으로는 메일·파일·조직 데이터에 접근 가능한 권한 창구를 확보하게 됩니다.

또 하나 흥미로운 지점은 OAuth 리디렉션 악용이 사용자 경험(UX)에 대한 신뢰를 이용한다는 것입니다. 사용자는 이미 대기업 로그인 화면, 조직 인증 페이지, 동의 화면에 익숙합니다. 그래서 URL 파라미터의 미세한 차이나 redirect 조합, state 값의 비정상성을 스스로 판별하기 어렵습니다. 공격자는 이 점을 압니다. 그래서 피싱 페이지를 완전히 위조하기보다, 오히려 정상 플로우에 최대한 올라타려 합니다. 사용자가 “보던 화면”을 보게 만드는 쪽이 훨씬 효율적이기 때문입니다.

디바이스 코드 피싱도 같은 맥락입니다. 표면적으로는 사용자가 정식 인증 절차를 수행하는 것처럼 보입니다. 공격자는 여기에 시간 압박, 반복 안내, 보조 메일, QR 코드, 긴급 업무 요청 같은 요소를 덧붙여 정상 흐름처럼 포장합니다. 제가 이 부분을 특히 위험하다고 보는 이유는, 많은 사용자 교육이 아직도 “비밀번호를 입력하지 마라” 수준에 머물러 있기 때문입니다. 그런데 디바이스 코드 피싱은 사용자가 비밀번호를 직접 넘기지 않아도 성립할 수 있습니다. 사용자는 오히려 “안전하게 공식 페이지에서 코드만 입력했다”고 생각할 가능성도 있습니다.

 

3. 취약점 진단 관점에서 왜 중요한가

 

진단 실무에서 이 주제가 중요한 이유는, 진단 범위를 ‘로그인 보안’에서 ‘동의와 권한 위임 보안’까지 확장해야 하기 때문입니다.

예전에는 인증 로그, 로그인 실패율, MFA 우회 가능성 같은 것만 점검해도 일정 부분 위협을 설명할 수 있었습니다. 하지만 OAuth 기반 환경에서는 그것만으로는 부족합니다. 누가 어떤 앱을 등록했는지, 어떤 스코프를 요청했는지, 관리자 동의가 개입되었는지, 기존 승인 앱 목록과 실제 업무용 애플리케이션 목록 사이에 어떤 불일치가 있는지까지 함께 봐야 합니다.

실제 진단이나 사고 분석에서 제가 중요하게 보는 조합은 다음과 같습니다.
“새 애플리케이션 등록” + “과도한 권한 요청” + “위험 징후가 있는 계정/행위 주체” 입니다.

취약사례

예를 들어 최근 생성된 앱이 Mail.ReadWrite, Files.ReadWrite.All 같은 권한을 요구하고, 그 승인 시점에 계정 위험도가 높거나 위치·클라이언트가 비정상적이라면, 그건 단순한 설정 이벤트가 아니라 침해 신호일 수 있습니다. 반대로 이러한 이벤트가 남아 있는데도 단순 로그인 성공/실패 관점만 보면 놓치기 쉽습니다.

또 하나 자주 느끼는 것은, 많은 조직이 승인된 앱 목록의 관리와 검토를 너무 느슨하게 한다는 점입니다. 실제 업무에 쓰는 앱은 몇 개 되지 않는데, 환경 안에는 이름이 모호한 앱이 계속 누적되고, 누가 만들었는지도 알지 못하는 경우가 있습니다. 이건 기술적으로도 문제지만 운영적으로도 위험합니다. 결국 OAuth 보안은 설정의 문제가 아니라 권한 위임에 대한 자산관리 문제이기도 합니다.

 

---

 

4. 진단 시 먼저 보는 지점

 

실무에서 이 이슈를 검토할 때 우선 로그인만 보지 않고, 동의·앱 등록·권한 변경 이벤트를 하나씩 묶어 이용자가 접근하는 시간순으로 재배열합니다. 이 작업을 해보면 생각보다 많은 것이 보입니다. 로그인 이벤트 하나만 볼 때는 정상처럼 보이던 것도, 그 직전에 앱 등록이 있었고 그 직후 과도한 권한 동의가 이어졌다면 해석이 완전히 달라집니다.

 

 

그 다음에는 앱 단위 리스크 클러스터링을 합니다. 최근 생성된 앱 ID, Redirect URI, 요청 권한 스코프, 발급된 토큰 유형을 기준으로 묶어서 보면 이상치가 꽤 잘 드러납니다. 업무용으로 보기 어려운 이름, 비정상적으로 넓은 권한 조합, 조직 내 기준선과 어긋나는 Redirect URI 패턴은 특히 눈여겨봅니다.

리허설 환경이 확보된다면, 가능하면 동의 시나리오를 직접 재현해보는 편입니다. 여기서 중요한 것은 단순히 “로그인이 된다/안 된다”가 아니라, 최종적으로 어떤 토큰이 발급되는지, 액세스 토큰인지 리프레시 토큰인지, 어떤 리소스 접근이 가능한지까지 확인하는 것입니다. 보고서 설득력도 이 단계에서 크게 달라집니다. 동의 화면의 스코프, Redirect 흐름, 토큰 유형이 스냅샷과 함께 남아 있으면, 해당 이슈를 설계상 리스크로 설명하기가 훨씬 수월합니다.

기술적으로는 다음 항목을 특히 중요하게 봅니다.

 

• Redirect URI가 exact-match로 강제되는지
• 과도하게 넓은 패턴이나 와일드카드가 허용되는지
• state, nonce, PKCE가 단순 적용에 그치지 않고 실제 검증까지 정합하게 구현되어 있는지
• 승인된 앱 목록과 실제 업무 애플리케이션 목록 사이에 드리프트가 존재하는지
• Delegate 권한과 Application 권한이 혼재되며 과도하게 열려 있지 않은지

 

여기서 특히 state나 PKCE는 “설정은 되어 있다”는 이유만으로 안심하면 안 됩니다. 실제로는 값이 존재만 하고 검증 로직이 느슨하거나, 커스텀 연동 앱에서 구현이 부분적으로만 적용된 경우가 적지 않습니다. 겉으로 OAuth 보안조치가 들어간 것처럼 보여도, 검증 정합성이 떨어지면 공격 표면은 그대로 남습니다.

 

---

 

5. 대응방안은 '인증 강화'만으로 충분한가

 

많은 조직이 이런 이야기를 들으면 바로 MFA 강화나 비밀번호 정책 강화부터 떠올립니다. 물론 그것도 필요합니다. 하지만 이 문제는 본질적으로 인증 문제라기보다 위임된 권한의 통제 문제에 가깝습니다. 공격자는 사용자의 비밀번호를 훔치지 않고도 원하는 결과에 도달할 수 있기 때문입니다.

그래서 대응의 우선순위는 조금 달라져야 합니다.

가장 먼저 필요한 것은 동의 승인 게이트를 엄격하게 두는 것입니다. 로그인만 성공한다고 모든 권한을 주어서는 안됩니다. 민감 권한을 요청하는 앱은 사용자 자율 동의가 아니라 관리자 승인 전용으로 돌리고, 공개 카탈로그나 사전 검증된 앱만 허용하는 방식으로 표면을 줄여야 합니다. 사용자가 무엇이든 동의할 수 있게 열어둔 환경에서는 결국 교육만으로 버티기 어렵습니다.

두 번째는 Redirect URI 하드닝입니다. exact-match, HTTPS 강제, 사전 등록된 도메인 제한은 기본값이어야 합니다. 예외적으로 넓게 열어둔 패턴은 실무 편의상 유지되는 경우가 많지만, 이런 예외가 공격자에게 가장 먼저 악용됩니다.

세 번째는 기준선 기반 탐지 체계입니다. 새 앱 생성 급증, 비업무 시간 앱 승인, 과도한 스코프 조합, 디바이스 코드 반복 시도 같은 흐름은 별도로 관리하는 것이 좋습니다. 단일 이벤트로 보면 노이즈처럼 보여도, 연쇄적으로 엮으면 꽤 강한 공격 체인이 됩니다.

네 번째는 보고와 교육 방식의 수정입니다. 사용자에게 “수상한 로그인에 주의하라”는 식의 메시지만 반복하는 것은 한계가 있습니다. 오히려 “당신이 동의한 앱은 메일과 파일을 어디까지 읽을 수 있는가”를 시각적으로 설명하는 편이 더 효과적입니다. 사용자는 로그인은 익숙하지만, 권한 위임의 결과는 체감하지 못하는 경우가 많기 때문입니다.

 

6. AI의 발전, 그럼에도 기본에 충실해야하는 이유

 

개인적으로는 이 영역이 앞으로의 취약점 진단에서 더 비중이 커질 것이라고 봅니다. 이유는 간단합니다. 이제 많은 조직이 비밀번호 정책, MFA, 조건부 접근 같은 전통적 통제를 어느 정도 갖추기 시작했기 때문입니다. 반면 권한 위임, 승인된 앱 관리, 장기 토큰 운영 통제는 상대적으로 느슨한 경우가 많습니다. 공격자는 항상 상대적으로 약한 고리를 찾습니다. 지금 그 고리 중 하나가 OAuth 동의 구조라고 생각합니다.

 

특히 최근에는 개발 업무 전반에 AI가 빠르게 도입되면서, 인증 기능 자체를 구현하는 진입장벽은 과거보다 훨씬 낮아졌습니다. 최근에는 AI를 활용해 OAuth/OIDC 연동 자체는 빠르게 구현할 수 있게 되었지만, 정작 더 중요한 ‘누가 무엇에 어디까지 접근 가능한가’에 대한 권한 설계 검증은 자동으로 해결되지 않습니다. 인증 구현이 쉬워진 만큼, 서비스와 연동 앱은 더 빠르게 늘어나고, 그 과정에서 누가 어떤 자산에 어떤 범위로 접근 가능한지에 대한 전체 권한 매트릭스는 오히려 더 불투명해지고 복잡해질 수 있습니다. 즉, 로그인 기능은 더 정교해졌는데, 그 뒤에 연결된 권한 동의 구조와 위임 관계는 충분히 검증되지 않은 채 확장될 가능성이 커진 것입니다. 저는 이 지점이 앞으로 더 위험해질 수 있다고 봅니다. 구현 속도가 빨라진 환경에서는 인증이 안전해 보인다는 이유만으로 전체 권한 구조까지 안전하다고 오해하기 쉽기 때문입니다.

 

AI는 인증 구현의 속도를 높여주지만, 권한 설계의 책임까지 대신 져주지는 않습니다.

 

저는 진단 업무를 하면서 점점 더 분명하게 느끼는 것이 있습니다. 비밀번호 보안에서 권한 보안으로 초점이 이동하는 순간을 놓치면, 실제 위협을 늦게 보게 된다는 점입니다. OAuth는 단순히 편리한 로그인 연동 기술이 아니라, 조직 자산의 일부 운영권을 외부 애플리케이션에 넘기는 인터페이스입니다. 그래서 이 영역을 점검할 때는 단순 취약점 체크리스트 수준이 아니라, “누가 언제 어떤 권한을 어떤 경로로 위임했는가”를 재현 가능하고 증빙 가능한 형태로 남겨야 합니다.

 

실무 5년차쯤 되면 오히려 더 조심스러워지는 부분도 있습니다. 예전에는 취약점 하나를 식별하면 그 자체로 명확하다고 느꼈다면, 지금은 설계와 운영의 경계에 있는 리스크일수록 더 많이 고민하게 됩니다. OAuth 관련 이슈가 특히 그렇습니다. 겉으로는 정상 기능이고, 사용자는 실제로 동의했고, 토큰도 합법적으로 발급되었습니다. 그런데 그 결과가 조직 입장에서는 침해와 다를 바 없을 수 있습니다. 저는 이런 지점이야말로 앞으로 취약점 진단가가 더 집요하게 다뤄야 할 영역이라고 봅니다.