OAuth에 대한 고찰

태규 최·2022년 2월 1일

Spring-Security

목록 보기

4/5

스프링 시큐리티를 공부하고 프로젝트를 진행하다가 OAuth를 사용하게 되었는데 가져다 쓰기만 할줄 알고 제대로 된 정리가 필요 할 것 같아서 작성하게 되었다.

OAuth 가 만들어지게 된 계기

OAuth 이전에는 타 프로그램의 계정에 권한을 부여하는 방식은 단순히 사용자의 아이디와 비밀번호를 사용하는 방법이었다.

이러한 방식은 사용자 권한으로 서비스에 로그인해야 하는 필요가 있었으며, 이러한 방식은 비밀번호를 평문으로 저장하기 때문에 보안적으로 위험했다.

이러한 문제들을 해결하기 위해서 많은 회사들이 자사의 인증 방법들을 개발했다.

Flickr : FlickrAuth
Google : AuthSub
FaceBook : 각 애플리케이션에 secret을 발행 해주고 요청시마다 이를 MD5 방식으로 암호화 해서 전송
Yahoo : BBAuth(브라우저 기반)

등등 방법이 있었고 이 방식들은 서로 완벽하게 호환되지 않고 특정 보안 고려 사항을 해결하지 못한다는 단점이 있다!

2006년 11월 경 트위터 소속 개발자인 Blaine Cook은 다른 타사의 OpenId를 개발하는 인원들과 함께 온라인 커뮤니티를 만들었다. 이들의 목적은 모든 시스템에서 사용할 수 있는 api 제어 표준을 만들어서 사용하는 것이다!

커뮤니티 팀원들은 여러 소속 개발자들이 함께 개발해서 OAuth1.0을 공개하게 되었다.

OAuth 1.0 vs 2.0

OAuth 1.0은 초기에 만들어 진것이고 Flickr와 Google의 AuthSub를 기반으로 작업을 했다.

OAUth 1 api는 이 api를 구축하는 회사와 이를 개발하는 개발자에게 OAUth 1.o 프로토콜이 매우 어렵다고 느끼게 되었다.

인증 및 서명

OAuth 1.0 의 대다수의 어려움을 느꼈던 부분은 암호화 부분이었다. 1.0에서는 사용자 이름/ 비밀번호 인증의 간단함 때문이다.

1.0 에서는 매 요청마다 암호화 서명이 필요하게 되었고 개발자는 서명을 하기 위해 라이브러리를 설치하고 서명방법을 정의해야 했다.

2.0 에서는 Bearer 토큰을 이용해서 요청을 하기 때문에 사용자 서명을 해야 할 필요가 없다.
또한 보안을 HTTPS 프로토콜로 위임하기 때문에 전체 인증 과정이 1.0 보다 한단계 적다.

사용자 경험 및 Refresh 토큰 발행

OAuth 2.0 에는 두가지 파트로 나뉘어져 있다

사용자의 권한 부여
액세스 토큰을 사용해서 사용자를 대신해서 요청

반면에 1.0은 세가지 부분으로 나뉘어져 있다.

Consumer는 승인되지 않은 요청 토큰을 얻는다.
Service provider는 요청 승인한다.
Consumer는 요청 토큰을 액세스 토큰으로 교환해서 사용한다.

1.0은 웹 기반 애플리케이션 , 데스크톱 , 모바일 3가지 흐름으로 나뉘어 져서 개발이 되기 시작했다.

그렇지만 시간이 흐름에따라 세가지 방식이 하나로 병합할 수 있게 되었다.

역할 분리

Oauth 2.0에 중요한 디자인 중 하나는 api 서버에서 권한 부여 부분을 분리한 것이다.
인증 서버는 애플리케이션의 클라이언트 아이디와 secret 만을 알면되고 api 서버는 액세스 토큰만을 받기 때문에 분리 할수가 있다.
이 서버들은 물리적으로 분리가 되어있는 서버 일 수도 있다.

이를 분리함으로써 얻는 장점은