[CS] OAuth

.onNext("Volga")·2023년 1월 31일

computer science

Computer Science

목록 보기

6/6

OAuth

오늘은 OAuth에 대해 간단하게 알아봅니다.

오늘 할 Task

OAuth란?
왜 필요할까?
인증 과정

OAuth란?

OAuth("Open Authorization")는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 이 매커니즘은 여러 기업들에 의해 사용되는데, 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹사이트의 계정에 관한 정보를 공유할 수 있게 허용한다.

출처: wiki 백과

왜 사용 할까?

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조일 가능성이 매우 많다.

기본 인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였다. 예를 들면 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있다.

OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다.

출처: wiki 백과

일단 위키 문서의 내용을 차근차근 읽어보겠습니다.

OAuth 방식 사용 전에는 인증 방식의 표준이 없었다.
기본인증은 아이디 / 비밀번호를 사용한다.
기본인증은 취약한 구조다.
또한, 기본 인증을 사용하지 않는 경우에는 Application 개발 회사의 방법대로 사용자를 확인한다.
OAuth는 제각각인 사용자 확인(인증)방식을 표준화한 인증 방식이다.
따라서 OAuth를 사용하면 해당 인증을 공유하는 App들 끼리는 별도의 인증을 하지 않는다.

예전에 어떠한 서비스에 대하여 사용자로 인증을 하는 경우에는 어떠한 서비스에서 가입했던 아이디와 비밀번호를 입력해서 인증을 하고 로그인을 했었습니다.

이러한 방식을 기본 방식이라고 부르는 것 같습니다.

근데, 이 방식이 취약한 구조라고 위키에서는 제공하고 있는데 그래서 왜? 무엇이? 취약한지 궁금해서 한번 알아봤는데 이에 대해 간단히 또 알아봅시다.

기본인증은 왜 취약할까?

대부분의 포스팅이나 칼럼에서는 기본인증의 취약점은 가짜 서버 위장에 취약하다라고 제시가 되어있습니다.

가짜 서버에 연결이 되어 있지만 사용자는 검증된 서버에 연결되어 있다고 믿고 개인정보(아이디/비밀번호)를 노출 할 위험이 있기 때문입니다.

그리고 OAuth 인증방식은 요새 흔히 앱에 로그인할때

위와 같은 로그인 방식을 볼텐데 다른 앱의 인증 정보를 OAuth 프로토콜로 표준화한 방식이라고 생각이 듭니다.

왜 사용할까? 의 결론

OAuth를 사용하는 이유는 다른 서비스의 회원 정보를 안전하게 사용하기 위해서이다.

인증 방식

간단하게 인증방식에 대해 알아봅니다.

용어를 먼저 정리할 필요가 있어서 용어에 대해 먼저 알아봅니다!

용어

사용자 (User): 서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인
소비자 (Consumer): Open API를 이용해서 개발된 OAuth를 사용해서 서비스 제공자에게 접근하는 웹사이트 또는 어플리케이션
서비스 제공자 (Service Provider): OAuth를 통해 접근을 지원하는 웹 어플리케이션(Open API를 제공하는 서비스)
소비자 비밀번호 (Consumer Secret): 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
요청 토큰 (Request Token): 소비자가 사용자에게 접근 권한을 인증받기 위해 필요한 정보가 담겨져 있으며 후에 접근 토큰으로 변환 됩니다.
접근 토큰 (Access Token): 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해 보호된 자원에 대해 접근하기 위한 키를 포함한 값을 말합니다.

방식에 대한 그림을 한번 알아봅시다.

출처: https://oauth.net/core/diagram.png

순서대로 한번 알아보게 되면 다음과 같습니다.

먼저 Consumer가 Service Provider에게 Request Token을 요청합니다.
Service Provider가 Consumer에게 Request Token을 발급해 줍니다.
Consumer가 User를 Service Provider 와 연결합니다.
Service Provider가 User를 Consumer에게 연결합니다.
Consumer가 된 User가 접근 토큰을 요청하게 됩니다.
Service Provider가 Access Token을 Consumer에게 발급 해 줍니다.
발급된 Access Token을 이용해서 Consumer에서 사용자 정보에 접근하게 됩니다.

아마 위의 순서에서 3, 4번 항목이 좀 이해가 잘 안될수도 있는데 실상은 아주 간단하고 또 익숙한 얘기입니다.

예를들어, velog에 로그인을 한다고 가정 해 봅시다!!

그러면 위의 사진과 같이 소셜로그인 항목이 나오게 됩니다.
간단하게 구글 계정으로 로그인을 한다고 가정을 해보면

위와 같이 구글 로그인 화면으로 변경이 됩니다.

이것을 정리해 본다면,

일단, 나는 User에 해당합니다.
그리고 현재 내가 로그인하고자 하는 Application은 Velog이고, Velog는 Consumer의 역할이 됩니다.
또한, OAuth에 필요한 Token같은 것들을 발행해주는 Service Provider는 여기서는 Google이 되는 것이죠.