OAuth (인증 위임 프로토콜)
쉽게 풀면
OAuth는 발레파킹을 맡길 때 자동차 열쇠 전체가 아니라 '주차만 가능한 임시 열쇠'를 건네주는 것과 비슷합니다. 예를 들어 어떤 사진 인화 서비스가 '내 구글 사진첩'에 접근하게 해주고 싶다고 합시다. 이때 구글 아이디와 비밀번호를 그 서비스에 직접 알려주는 것은 위험합니다. 대신 OAuth를 쓰면, 사용자는 구글 로그인 화면에서 '이 서비스가 내 사진첩만 볼 수 있도록 허용할게'라고 승인만 하고, 구글은 그 서비스에게 '사진첩 조회만 가능한 임시 통행증(토큰)'을 발급합니다. 그 서비스는 비밀번호를 몰라도 사진첩에만 접근할 수 있고, 사용자는 언제든 이 통행증을 회수할 수 있습니다.
왜 중요한가
OAuth는 여러 서비스가 서로 연동되는 오늘날의 웹·모바일 생태계에서 비밀번호를 직접 공유하지 않고도 권한을 안전하게 위임할 수 있게 해주는 표준 방식이기 때문에, 정보보안, 분산 시스템, API 설계를 다루는 논문에서 인증·인가 아키텍처를 설명할 때 기본 전제로 자주 등장합니다. 마이크로서비스 구조나 클라우드 서비스 간 연동이 늘어나면서, 각 서비스가 필요한 최소 권한만 부여받도록 설계하는 최소권한 원칙과 함께 다뤄지는 경우도 많습니다.
논문에서는 이렇게 쓰입니다
이 문장은 정보보안이나 소프트웨어 아키텍처를 다루는 논문에서, 비밀번호를 직접 공유하지 않고도 안전하게 여러 서비스를 연동하는 인증 설계를 설명할 때 등장합니다. OAuth는 비밀번호 노출 위험을 줄이면서도 필요한 권한만 제한적으로 부여할 수 있어, 보안성을 강조하는 시스템 설계 연구에서 자주 인용됩니다.
분산 시스템·클라우드 아키텍처 논문에서는 사용자가 아닌 서비스와 서비스 사이의 인증에도 OAuth가 활용되는 사례를 다룰 때 이런 표현을 씁니다.
모바일 보안 연구에서는 OAuth의 기본 흐름에 추가 보안 장치를 결합한 확장 방식을 소개할 때 이런 문장이 등장합니다.
조금 더 깊게 보면
OAuth는 접근 권한을 나타내는 접근 토큰(access token)과, 그 토큰이 만료되었을 때 새로 발급받기 위한 재발급 토큰(refresh token)을 구분해서 사용하는 구조가 특징입니다. 또한 사용 목적에 따라 서버 간 인증에 쓰이는 클라이언트 자격증명 방식, 사용자가 직접 로그인하는 인가 코드 방식 등 여러 흐름(grant type)이 존재하며, 논문에서는 시스템의 특성에 맞는 흐름을 선택한 이유를 함께 설명하는 경우가 많습니다. 참고로 사용자의 신원 자체를 확인하는 기능은 OAuth 위에 OpenID Connect라는 별도 계층을 얹어 구현하는 것이 일반적입니다.
주의할 점
OAuth는 '인증(내가 누구인지 확인)'이 아니라 원래 '인가(무엇을 할 수 있는지 허락)'를 위해 설계된 프로토콜입니다. 로그인 기능 자체를 위해서는 OAuth 위에 신원 확인 절차를 얹은 별도 계층이 함께 쓰이는 경우가 많다는 점에 주의해야 합니다. 발급된 토큰이 중간에 가로채이지 않도록 전송계층보안 같은 암호화 통신과 함께 사용하는 것도 필수적입니다.