개요

---

사이드 프로젝트를 하다가 Oauth라는 것을 알게 됐다. 소셜 로그인 기능 구현 전에 Oauth 개념에 대해서 알아보기 위해서 공부를 하고 넘어가려고 한다.

Oauth1은 알려진 보안 이슈에 대해서 Oauth1 말고 Oauth2를 소개하려고 한다.

⁉️ Oauth

---

Oauth란 사용자가 Password를 제공하지 않으면서 다름 어플리케이션에서 자신의 정보들을 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로 사용되는 접근 위임을 위한 개방형 표준이다.

Oauth가 사용되기 전에는 인증방식 표준이 없어서 기존의 인증 방식인 아이디와 비밀번호를 사용해서 기본인증을 해왔다.

하지만 보안상 취약한 구조일 가능성이 매우 높아서 기본 인증이 아닐 경우는 각 앱에서 각자 개발한 회사의 방법대로 사용자를 확인했다.

• 각 회사가 개발한 인증 방식
  1. Google - AuthSub
  2. AOL - OpenAuth
  3. Yahoo - BBAuth
  4. Amazon - Web Service API

Oauth는 이런 제각각의 인증 방식을 표준화한 인증 방식이다. Oauth를 이용하면 이 인증을 공유하는 앱끼리는 별도의 인증이 필요없고, 여러 앱을 하나의 인증으로 통합 사용을 할 수 있다.

Oauth 1.0 구성

---

용어	설명
사용자	서비스 제공자의 소비자를 사용하는 계정을 가지고 있는 개인
소비자	Open API로 개발된 Oauth를 사용해서 서비스 제공자에게 접근하는 애플리케이션
서비스 제공자	Oauth를 통해 접근을 지원하는 애플리케이션
소비자 비밀번호	서비스 제공자에게 소비자임을 인증하기 위한 키
요청 토큰	소비자가 사용자에게 접근 권한을 인증받기 위해 필요한 정보가 담겨있는 토큰
접근 토큰	인증 후 사용자가 서비스 제공자가 아닌 소비자를 통해서 자원 접근을 허락하는 키를 갖고있는 토큰

Oauth 1.0 인증 방식

---

소비자가 서비스 제공자에게 요청 토큰 요청. → 서비스 제공자가 소비자엑 요청 토큰 발급. →

소비자가 사용자를 서비스 제공자로 이동 (사용자 인증이 수향) →

서비스 제공자가 사용자를 소비자로 이동 → 소비자가 접근 토큰을 요청 → 제공자가 접근 토크를 발행. →

발급된 접근 토큰을 이용해서 소비자가 사용자 정보에 접근.

Oauth는 총 고객, 고객이 이용하려는 애플리케이션, 고객 정보를 가지고 있는 애플리케이션 이 3가지가 상호작용하는 형태다.
구현이 복잡하며 HMAC을 통한 암호화를 하는 번거로움, 인증 토큰이 만료가 되지 않아 토큰을 만료하려면 제공자 애플리케이션의 비밀번호를 바꿔야해서 Oauth 2.0이 등장.

Oauth 2.0

Oauth 1.0에 비해 2.0에서는 1.0의 단점들을 개선하여 나왔다. 개선된 점은 아래와 같다.

1. 기능 단순화, 기능과 규모의 확장성 등 지원하기 위해 나옴.
2. https를 통해서 암호화를 하여 과정의 단순화.
3. 다양한 인증 방식이 제공.
4. API 서버에서 인증 서버와 리소스 서버가 분리.

Oatuh 2.0 구성

용어	설명
Resource owner	사용자
Client	Resource Server에서 제공하는 자원을 사용하는 애플리케이션
Resource Server ( API Server )	자원을 호스팅하는 서버
Authorization Server	사용자의 동의를 받아서 권한을 부여하는 서버, 일반적으로 Resource Server와 같은 URL 하위에 있는 경우가 많음.

Oauth 2.0 인증 방식

Oauth 2.0 인증 과정

Oauth 2.0 프로세스

• 1 ~ 5 단계 : Authorization Code 발급 요청 URL을 통해서 진행.
• 7 ~ 8 단계 : 서비스에서 Callback URL을 통해 전달받은 Authorization Code를 사용해서 Access Token을 요청 API를 통해 진행.
• 8단계에서 발급 받은 Access Token은 서비스에서 자체적으로 저장 및 관리.
• 10 ~ 11단계 사용자의 서비스 요청 시 회원정보가 필요하면 Access Token을 통해서 API 호출 가능.