OAuth 2.0 인가코드 흐름 (OAuth 2.0 Authorization Code Flow)
쉽게 풀면
호텔에 체크인할 때 방 열쇠 자체를 주는 대신, 프론트에서 발급한 임시 카드로 필요한 곳만 출입하게 하는 것과 비슷합니다. 어떤 앱이 여러분의 구글 계정 정보를 이용하고 싶을 때, 구글 아이디와 비밀번호를 그 앱에 직접 입력하는 대신 구글 로그인 화면에서 동의만 하면, 구글이 짧게 쓰이는 인가 코드를 앱에 넘겨줍니다. 앱은 이 코드를 다시 구글 서버에 제시해 실제 접근 토큰을 발급받습니다. 이렇게 비밀번호가 중간에 노출되지 않고도 권한을 위임할 수 있는 것이 이 흐름의 핵심입니다.
왜 중요한가
여러 서비스가 서로 연동되는 현대 웹 생태계에서, 사용자 비밀번호를 여러 곳에 나누어 저장하지 않고도 안전하게 권한을 위임할 수 있는 표준 방법이 필요했습니다. 인가코드 흐름은 이러한 요구를 충족시키는 가장 널리 쓰이는 OAuth 2.0 방식으로, 인증 및 접근제어 연구와 실무에서 기본 참조 모델로 다뤄집니다.
논문에서는 이렇게 쓰입니다
인가 코드 방식을 사용해 민감한 토큰이 브라우저 등에 직접 드러나지 않게 보안을 강화했다는 설계 의도를 설명하는 문장입니다.
기본 인가코드 흐름에 추가 보안 절차를 더해 특정 환경에서의 취약점을 보완한 사례를 설명하는 문장입니다.
조금 더 깊게 보면
이 흐름은 크게 사용자가 인가 서버에서 로그인 및 동의하는 단계, 인가 서버가 클라이언트에게 임시 인가 코드를 전달하는 단계, 클라이언트가 그 코드를 이용해 백채널로 액세스 토큰을 교환받는 단계로 구성됩니다. 모바일 앱이나 단일 페이지 애플리케이션처럼 클라이언트 시크릿을 안전하게 보관하기 어려운 환경에서는 PKCE라는 추가 검증 절차를 함께 사용하는 것이 권장됩니다.
주의할 점
인가 코드는 짧은 시간만 유효하도록 설계되어 있으며, 이를 재사용하거나 탈취당하지 않도록 리다이렉트 URI 검증과 같은 절차를 반드시 지켜야 합니다. 인가코드 흐름 자체가 안전하더라도 구현이 부실하면 취약점이 발생할 수 있습니다.