Authentication - OAuth 2.0

우리는 웹이나 앱에서 흔히 찾아볼 수 있는 소셜 로그인 인증 방식은 OAuth 2라는 기술을 바탕으로 구현된다.

전통적으로 직접 작성한 서버에서 인증을 처리해주는 것과는 달리, OAuth는 인증을 중개해주는 메커니즘이다.

보안된 리소스에 액세스 하기 위해 클라이언트에게 권한을 제공하는 프로세스를 단순화하는 프로토콜이다.

즉, 이미 사용자 정보를 가지고 있는 웹 서비스(GitHub, google, facebook 등)에서 사용자의 인증을 대신해주고, 접근 권한에 대한 토큰을 발급한 후, 이를 이용해 내 서버에서 인증이 가능해진다.

 

OAuth가 모든 것을 해결해주는 설루션은 아니다.

여전히 사용자 정보가 내 서버에 저장되는 것은 변함이 없다.

OAuth는 인증(Authentication)을 다른 서비스에 맡길 뿐, 접근 권한 관리(Authorization)는 순전히 내 서버의 몫이다.

그러므로, OAuth의 작동 방식을 알기 위해서는 기존 인증 방식에 대한 이해가 필수적이다.

 

질문: Authentication과 Authorization의 차이가 무엇인가요?

인증(Authentication) : 자신이 누구라고 주장하는 사람을 확인하는 절차이다.

권한 부여 (인가) (Authorization) : 요구하는 정보나 리소스에 접근할 수 있도록 허용하는 것

 

✏️OAuth(Open Authorization)란?

OAuth 2.0은 인증(Authentication)을 위한 표준 프로토콜의 한 종류

보안된 리소스에 액세스 하기 위해 클라이언트에게 권한을 제공(Authorization)하는 프로세스를 단순화하는 프로토콜 중 한 방법이다.

OAuth는 RFC표준으로 등록되어 있는 토큰 기반 인증방식이다.

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

 

 

🤷‍♀️OAuth는 왜 사용할까?

유저 입장에서 생각해보자면, 우리는 웹 상에서 굉장히 많은 서비스들을 이용하고 있고 각각의 서비스들을 이용하기 위해서는 회원가입 절차가 필요한 경우가 대부분이다.

그 서비스별로 ID와 Password를 다 기억하는 것은 매우 귀찮은 일이다.

OAuth를 활용한다면 자주 사용하고 중요한 서비스들(예를 들어 google, github, facebook)의 ID와 Password만 기억해 놓고 해당 서비스들을 통해서 소셜 로그인을 할 수 있다.

뿐만 아니라 OAuth는 보안상의 이점도 있다. 

검증되지 않은 App에서 OAuth를 사용하여 로그인한다면, 직접 유저의 민감한 정보가 App에 노출될 일이 없고 인증 권한에 대한 허가를 미리 유저에게 구해야 되기 때문에 더 안전하게 사용할 수 있다.

 

OAuth 작동방식과 용어들

---

OAuth는 1.0a, 2.0 두 가지 버전이 있고, 작동방식은 조금씩 다르다.

 

1.0a

1. API를 사용하는 클라이언트가 '필요한 권한을 가지고 있는지' 확인하며, Access Token을 획득한 방법까지 알 수 있다.

2. 자신을 증면하는 인증 권한을 확인하는 인가 작업을 모두 수행한다. 따라서 2.0보다 안전하다.

3. 2.0에 비해 인증과정이 복잡하고, 표준에서 요구하는 Signature, request Token 등의 보안요소를 직접 구현해야 하므로 완성 시간이 오래 걸린다.

 

2.0

1. 1.0a에 있는 인증절차가 삭제되고, 인가 절차만 있어서 사용이 쉽다.

2. 권한을 확인하는 데 사용할 Access Token을 어디서 얻었는지 확인할 방법이 없다. => 가로채기 공격에 취약하다.

3. 제거된 인증 기능을 보완할 방법이 개발자의 책임

3.1 대표적인 보완책 중 하나가 HTTPS + OAuth 2.0 HTTPS의 암호화를 활용해 가로채기 공격을 막는 것이다.

3.2 상황에 따라 Access Token의 유효기간을 분 단위로 줄이거나, 발급한 IP주소에서만 토큰 사용이 가능하도록 만드는 등의 강화된 보안정책을 적용하기도 한다.

 

용어들

- Resource Owner : 액세스 중인 리소스의 유저입니다.

김 코딩의 구글 계정을 이용하여 App에 로그인을 할 경우, 이때 Resource owner은 김 코딩이 됩니다.

- Client : Resource owner를 대신하여 보호된 리소스에 액세스 하는 응용프로그램입니다. 클라이언트는 서버, 데스크톱, 모바일 또는 기타 장치에서 호스팅 할 수 있습니다.

- Resource server : client의 요청을 수락하고 응답할 수 있는 서버입니다.

- Authorization server : Resource server가 액세스 토큰을 발급받는 서버입니다.

즉 클라이언트 및 리소스 소유자를 성공적으로 인증한 후 액세스 토큰을 발급하는 서버를 말합니다.

- Authorization grant : 클라이언트가 액세스 토큰을 얻을 때 사용하는 자격 증명의 유형입니다.

- Authorization code : access token을 발급받기 전에 필요한 code입니다.

client ID로 이 code를 받아온 후, client secret과 code를 이용해 Access token을 받아옵니다.

- Access token : 보호된 리소스에 액세스 하는 데 사용되는 credentials입니다. Authorization code와 client secret을 이용해 받아온 이 Access token으로 이제 resource server에 접근을 할 수 있습니다.

- Scope : scope는 토큰의 권한을 정의합니다. 주어진 액세스 토큰을 사용하여 액세스 할 수 있는 리소스의 범위입니다.

Access Token과 Refresh Token

---

1. Access Token

- 요청 절차를 정상적으로 종료한 클라이언트에게 발급

- 자원에 접근할 때 권한 확인용으로 사용

- 클라이언트에 발급된 권한의 대표(문자열 형태) 

- 계정 인증에 필요한 형태들을 표현

- 리소스 서버는 여러 가지 인증방식에 대응하지 않아도 권한을 확인할 수 있게 해 줌.

- 제한 시간이 있음.

 

2. Refresh Token

- Access token을 새로 발급받기 위해 필요.

- Access token 발급받을 때 같이 발급.

- token 형태는 Access Token과 동일(문자열) 

 

인증방식의 종류 => Grant type 종류

---

Grant type란 Client가 액세스 토큰을 얻는 방법을 뜻한다. => OAuth를 이용해서 권한을 획득하는 방법

아래 사진은 크게 4가지 종류만 있다고만 알아두고 가자.

나는 첫 번째 Authorization Code만 가볍게 정리해보려고 한다.

더 알아보고 싶다면 직접 검색해서 알아보자.

Grant type 종류

Authorization Code Grant

정의 : 액세스 토큰을 받아오기 위해 먼저 Authorization Code를 받아 액세스 토큰과 교환하는 방법이다.

페이스북 로그인 같은 소셜 로그인에서 쓰는 방식

 

특징

1. Authorization code 절차를 거치는 이유는 보안성 강화에 목적이 있다.

2. Client에서 client-secret을 공유하고 액세스 토큰을 가지고 오는 것은 탈취될 위험이 있다.

그래서 Client에서는 authorization code만 받아 오고 Server에서 Access token 요청을 진행한다.

 

아래 사진은 확대해서 한번씩 보고 넘어가도록 하자. 한 번에 보고 이해했다면 대단한 머리를 가지고 있는 것이다.

Authorization code

Refresh Token Grant Type

정의 : 일정 기간 유효 시간이 지나서 만료된 액세스 토큰을 편리하게 다시 받아오기 위해 사용하는 방법

 

특징

1. Access Token보다 Refresh Token의 유효 시간이 대체로 조금 더 길게 설정하기 때문에 가능하다.

2. server마다 Refresh token에 대한 정책이 다 다르기 때문에 Refresh token을 사용하기 위해선 사용하고자 하는 server의 정책을 살펴볼 필요가 있다.

 

질문

1. 왜 Refresh Token이 Access Token보다 유효 시간이 왜 더 길어요?

Access Token은 민감한 정보(개인 정보)를 가지고 있는 곳이라서 보안 때문에 시간이 짧다고 생각한다.

Refresh Token은 Authorization을 인증하는 데 사용하게 되고, Access Token은 Resource server에 접근할 때 사용하게 된다.

Resource server에는 더 민감한 정보들을 가지고 있고 Authorization(인증 기관) 이곳은 구글, 네이버, 카카오가 될 수도 있는 서버이다.

2. 그러면 인증은 딴 곳에서 하고, 민감한 정보가 담긴 정보(개인 정보)는 내 서버에서 확인해야 하는 것이 맞나요?

맞습니다. 내 서버로 들어오기 위해 Access Token을 사용해서 들어와야 한다.

3. 그럼 Access Token과 Refresh Token은 각각 사용하는 곳이 다른가요?

맞습니다. 위에 사진을 참고해보자 초록색이 Access Token, 노란색이 Refresh Token이다.

 

조금 더 자세하게 알아보고 싶다면 공식문서를 참고하자. 여기

NAVER 참고자료_1