요즘 시중에 SW 부트캠프가 많다.
그 중, 웹 개발 프로젝트를 진행하는 곳이 많은데 OAuth기능을 경험해본 웹 개발자 지망생들 또한 많다. 하지만 OAuth라고 했을때, 소셜로그인 정도로 알고 그치는 경우가 많고 나 역시 그렇기에 제대로된 개념과 OAuth1과 OAuth2의 차이를 알아보도록 하자

📌OAuth란?

애플리케이션 인증을 위한 접근 관한 개방형 표준 프로토콜

요즘 애플리케이션들을 이용하다보면 위 사진 처럼 직접 계정을 생성하거나, 타 애플리케이션의 계정을 공유하여 사용할 수 있는 모습을 자주 볼 수 있다. 쉽게 말해 타 계정을 사용해서 로그인 하는것이 OAuth이다.
그럼 OAuth의 정확한 개념과 프로세스는 뭘까?

✅ 개념

Open Authorization의 약자로 인터넷 사용자들이 비밀번호를 제공하지 않고, 다른 웹사의트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근권한을 부여할 수 있는 공통적인 수단으로 사용되는, 접근 위임을 위한 개방형 표준이다.

🕛개요

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조일 가능성이 매우 많다.
기본 인증이 아닐 경우는 각 애플리케이션이 각자 개발한 회사의 방법대로 사용자를 확인하였다.

• ex.
  • 구글의 AuthSub
  • AOL의 OpenAuth
  • 야후의 BBAuth
  • 아마존의 웹서비스 API

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

🕐 OAuth 1.0 구성

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

🕒 OAuth 1.0 인증 방식

사진 출처: showbugs.github.io
1. 소비자가 서비스 제공자에게 요청 토큰을 요청한다.
2. 서비스 제공자가 소비자에게 요청 토큰을 발급해준다.
3. 소비자가 사용자를 서비스 제공자로 이동시킨다. 여기서 사용자 인증이 수행
4. 서비스 제공자가 사용자를 소비자로 이동시킨다.
5. 소비자가 접근 토큰을 요청한다.
6. 제공자가 접근 토큰을 발행한다.
7. 발근된 접근 토큰을 이용하여 소비자가 사용자 정보에 접근한다.

즉 OAuth는 총 고객, 고객이 이용하려는 애플리케이션, 고객 정보를 가지고 있는 애플리케이션 이렇게 3개가 상호작용하는 형태이다.
구현이 복잡함,
HMAC(keyed-hash message authentication code, hash-based message authentication code)를 통한 암호화를 하는 번거로움,
인증토큰이 만료가 되지 않아 토큰을 만료하려면 제공자 애플리케이션의 비밀번호를 바꿔야 함
등으로 OAuth 2.0이 등장하였습니다.

📌 OAuth2?

⚡ OAuth 1.0과 달라진 점

1. 기능의 단순화, 기능과 규모의 확장성 등을 지원하기 위해 만들어졌다.
2. https를 통해 암호화를 하여 과정의 단수화를 하였다.
3. 다양한 인증 방식이 제공된다.
4. api서버에서 인증서버와 리소스 서버가 분리됐다.

🕛 OAuth 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 프로세스

사진 출처: 페이코 개발자센터 OAuth 2.0 프로세스

1-5 단계는 Authorization Code 발급 요청 URL을 통해 진행
7-8 단계는 서비스에서 callbackURL을 통해 전달받은 Authorization Code를 사용하여 Access Token을 요청 API를 통해 진행
8단계에서 발급받은 Access Token은 서비스에 자체적으로 저장, 관리
10-11단계 사용자의 서비스 요청시 회원정보가 필요하다면 AccessToken을 통해 API를 호출할 수 있습니다.

🕒 인증 종류

📌1. Authorization Code Grant

• 서버 사이트 코드로 인증하는 방식
• 권한 서버가 클라이언트와 리소스서버간의 중재 역할
• AccessToken을 바로 클라이언트로 전달하지 않아 잠재적 유출을 방지
• 로그인시에 페이지에 URL에 response-type=code 라고 넘김

📌2. Implicit Grant

• token과 scope에 대한 스펙 등은 다르지만 OAuth1.0과 가장 비슷한 인증 방식
• Public Client인 브라우저 기반의 애플리케이션이나 모바일 애플리케이션에서 이 방식을 사용하면 된다.
• OAuth 2.0에서 가장 많이 사용되는 방식
• 권한 코드 없이 바로 발급돼서 보안에 취약
• 주로 Read Only인 서비스에 사용
• 로그인시에 페이지 URL에 response_type=token 라고 넘김

📌3. Password Credentials Grant

• Client에 ID/PW를 저장해 놓고, ID/PW로 직접 accesstoken을 받아오는 방식
• Client를 믿을 수 없을 때에는 사용하기 위험해 APi 서비스의 공식 어플리케이션이나 믿을 수 있는 Client에 한해서 사용하는 것을 추천
• 로그인시에 API에 POST로 grant_type=credentails라고 넘김

📌4. Client Credentails Grant

• 어플리케이션이 Confidentail Client일 때, ID와 Secret을 가지고 인증하는 방식이다.
• 로그인시에 API에 POST로 grant_type=client_credentails라고 넘김

🕓 Token

📌Access Token

앞서 말한 4가지 방식 모두 정상적인 인증을 마치면 Access Token이 발급됩니다. 이 Token은 보호된 리소스에 접근할 때 권한 확인용으로 사용됩니다. 계정 ID와 PW 등 계정 인증에 필요한 형태들을 Token으로 표현함으로써, 리소스 서버는 여러 가지 인증 방식에 각각 대응 하지 않아도 권한을 확인 할 수 있게 됩니다.

📌Refresh Token

한번 발급받은 Access Token 은 사용할 수 있는 시간이 제한되어 있습니다. Access Token이 만료되면, 새로운 Access Token을 얻어야 하는데 그때 Refresh Token 이 활용됩니다.
권한 서버가 Access Token 을 발급해주는 시점에 Refresh Token 도 함께 발급하여 주기 때문에, 다른 절차 없이 Refresh Token을 미리 가지고 있습니다. 단 권한 서버에서만 활용되며 리소스 서버에는 전송되지 않습니다.

📌토큰의 갱신 과정

시간이 흐른 후 Access Token이 만료되면, 리소스 서버는 이후 요청들에 대해 오류를 응답하게 됩니다. Client는, 받아 두었던 Refresh Token을 권한 서버에 보내어 새로운 Access Token을 요청합니다. 갱신 요청을 받은 권한 서버는 Refresh Token의 유효성을 검증한 후, 문제가 없다면 새로운 액세스 토큰을 발급해줍니다. 이 과정에서 옵션에 따라 Refresh Token 도 새롭게 발급 될 수 있습니다

🔅레퍼런스

• Naver D2: https://d2.naver.com/helloworld/24942
• HMAC: https://ko.wikipedia.org/wiki/HMAC
• 호우의 블로그: https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C
• PAYCO 개발자센터: https://developers.payco.com/guide/development/apply/web