OAuth2.0란 무엇인가?

이번 메인 프로젝트의 목표 중 하나는 사용자들이 서비스를 더욱 간편하고 빠르게 이용할 수 있도록 하는 것이다.

이를 실현하기 위해 소셜 로그인 기능의 도입을 결정하였다.

소셜 로그인 구현에 있어서는 OAuth 2.0 프로토콜이 필수적이다.
그렇다면 이 OAuth 2.0은 대체 무엇일까? 이에 대해 지금 알아보는 시간을 갖도록 하겠다.

OAuth2.0 란?

---

OAuth2.0

OAuth 2.0은 인증에 대한 산업 표준 프로토콜로, '제 3자 애플리케이션'이 사용자를 대신해 HTTP 서비스를 이용할 수 있는 권한을 부여하는 메커니즘을 제공한다.
이 프로토콜은 사용자의 로그인 정보를 제 3자 앱이나 웹사이트와 공유하지 않고도, 해당 앱이나 웹사이트가 사용자의 대신에 특정 작업을 수행하도록 허용한다.

예를 들어, 한 사용자가 사진 공유 애플리케이션을 사용하고 있다고 가정해 보자. 이 사용자가 원한다면 이 애플리케이션에 Facebook 또는 Google 계정 정보를 제공함으로써, 애플리케이션은 사용자의 소셜 미디어 사진을 가져오거나, 소셜 미디어 계정에 새 사진을 게시하는 등의 작업을 수행할 수 있다.

이 과정에서 사용자는 사진 공유 애플리케이션에 직접 로그인 정보를 제공하지 않는다. 대신, 애플리케이션은 OAuth 2.0 인증 프로세스를 통해 이러한 권한을 부여받는다.

이 방식은 사용자의 로그인 정보를 보호하면서, 다양한 앱과 서비스 간에 편리한 연동성을 제공한다. 이런 이유로 OAuth 2.0은 많은 개발자와 조직에게 널리 채택되고 있다.

특히, 웹 애플리케이션뿐만 아니라 모바일 애플리케이션에서도 OAuth 2.0은 중요한 인증 방식으로 사용되고 있다.

로그인 없이 서비스를 이용

OAuth 2.0은 '인증'보다는 '권한 부여(authorization)'에 더 중점을 두는 프로토콜이다. OAuth 2.0의 주요 목표는 사용자의 아이디와 비밀번호를 공유하지 않고도, 제 3자 애플리케이션에 사용자를 대신해 특정 작업을 수행하도록 허용하는 것이다.

따라서 OAuth 2.0은 로그인 과정 자체를 담당하지 않는다. 대신, 이미 로그인한 사용자의 자원에 대한 접근 권한을 제 3자 애플리케이션에 부여하는 역할을 한다. 예를 들어, 소셜 미디어 사이트에 로그인한 사용자가 사진 공유 앱에서 자신의 소셜 미디어 사진을 사용하도록 허용하는 것이 가능하다.

하지만 OAuth 2.0 프로토콜이 소셜 로그인 시스템에서 널리 사용되는 이유는, 제 3자 애플리케이션을 사용자 이름과 비밀번호 없이 인증하는 매커니즘이 포함되어 있기 때문이다. 즉, OAuth 2.0을 사용하면 사용자는 예를 들어 Google 또는 Facebook 같은 신뢰할 수 있는 서비스 제공자를 통해 제 3자 애플리케이션에 로그인할 수 있다. 이 때, 신뢰할 수 있는 서비스 제공자는 사용자의 신원을 확인(즉, 로그인)하고, 이 정보를 제 3자 애플리케이션에 전달한다.

따라서 OAuth 2.0은 로그인 과정을 직접 다루지는 않지만, 인증과 밀접하게 연관되어 있다. 이 프로토콜을 통해 제 3자 애플리케이션이 사용자를 대신해 특정 작업을 수행하도록 허용하면서도, 사용자의 로그인 정보를 안전하게 보호할 수 있다.

OAuth2.0 용어

---

OAuth2.0은 용어가 많고 헷갈린다. 자주 나오는 용어들을 살펴보도록 하자

역할

이름	내용
Resource Owner (리소스 소유자)	리소스의 원래 소유자이다. 일반적으로 이는 사용자를 의미한다. 예를 들어, 사용자가 자신의 소셜 미디어 계정에 업로드한 사진에 대한 접근 권한을 허용하거나 거부할 수 있다. OAuth2.0에서는 이러한 사용자의 승인을 반드시 필요로 한다.
Client (클라이언트)	클라이언트는 OAuth2.0 용어로, 사용자의 리소스에 접근하려는 애플리케이션을 의미한다. 이 애플리케이션은 사용자의 명시적인 승인을 통해 사용자의 리소스에 접근할 권한을 얻는다. 예를 들어, 사용자가 음악 스트리밍 앱에서 자신의 소셜 미디어 친구 목록을 가져오는데 동의하면, 이 앱(클라이언트)은 사용자의 소셜 미디어 데이터에 접근할 수 있게 된다.
Resource Server (리소스 서버)	이 서버는 사용자의 데이터를 저장하고 있는 곳으로, 클라이언트가 이 서버를 통해 데이터에 접근한다. 이 서버는 클라이언트의 요청을 받아 인증 서버로부터 받은 접근 토큰을 검증하고, 이를 통과한 요청에 대해서만 데이터를 제공한다.
Authorization Server (인증 서버)	인증 서버는 클라이언트가 사용자의 데이터에 접근할 수 있도록 인증을 제공한다. 사용자의 승인을 받은 클라이언트에게 인증 서버는 접근 토큰을 발행한다. 이 토큰은 클라이언트가 리소스 서버에 접근할 때 사용된다.

용어

이름	내용
Authentication (인증)	인증은 리소스 소유자가 자신임을 증명하는 과정을 의미한다. 이는 일반적으로 사용자 이름과 비밀번호를 통해 이루어진다. 인증 과정을 통과한 사용자는 자신의 정보에 대한 접근 권한을 가지게 된다.
Authorization (인가)	인가는 인증된 사용자에게 특정 리소스에 접근하는 권한을 부여하는 과정이다. 사용자가 특정 애플리케이션을 통해 자신의 정보에 접근하도록 허용하면, 해당 애플리케이션이 사용자의 정보를 읽거나 쓸 수 있는 권한을 얻게 된다. 이 권한은 Access Token을 통해 애플리케이션에 부여된다.
Access Token (접근 토큰)	Access Token은 OAuth2.0 프로토콜에서 사용되는 보안 토큰이다. 이 토큰은 인가된 클라이언트가 리소스 서버에 접근할 수 있는 권한을 제공한다. 토큰에는 리소스 소유자의 신원, 인가된 권한, 토큰의 유효 기간 등의 정보가 포함된다. Access Token은 일정 기간 후 만료되므로, 기간이 만료되면 Refresh Token을 사용하여 새 토큰을 발급받아야 한다.
Refresh Token (갱신 토큰)	Refresh Token은 Access Token이 만료되었을 때 새로운 Access Token을 받기 위해 사용되는 토큰이다. Access Token은 보안상의 이유로 일정 시간 후에 만료되지만, Refresh Token을 사용하면 사용자가 다시 로그인하지 않아도 새로운 Access Token을 발급받을 수 있다. 이는 사용자 경험을 향상시키며, 동시에 보안을 유지한다.

OAuth2.0 권한 부여 방식

---

Authorization Code Grant (권한 부여 승인 코드 방식)

Authorization Code Grant (권한 부여 승인 코드 방식) 방식은 보편적으로 웹 애플리케이션에서 사용되는 가장 일반적인 OAuth 2.0 인증 방식.
이 방식은 리다이렉션을 통해 사용자의 인증과 인가를 처리하며, 사용자가 신뢰할 수 있는 인증 서버에서 인증을 받게 됩니다.

주요 단계

1. 사용자 인증 요청: 클라이언트 애플리케이션이 사용자를 인증 서버로 리다이렉트한다. 이 리다이렉트 요청은 클라이언트 애플리케이션의 식별자, 요청하는 접근 범위(scope), 리다이렉트 URI, 그리고 상태 정보를 포함하며, 이를 통해 인증 서버는 클라이언트 애플리케이션을 식별하고 인증 과정을 진행한다.

2. 사용자 인증: 인증 서버에서 사용자에게 로그인 페이지를 제공하여 사용자의 자격증명을 받는다. 이 정보는 클라이언트 애플리케이션에 전달되지 않는다.

3. 사용자 인가: 인증이 성공하면, 인증 서버는 사용자에게 클라이언트 애플리케이션이 요청하는 접근 범위에 대해 인가를 받는다.

4. 인증 코드 발급: 사용자가 인가를 승인하면, 인증 서버는 사용자를 클라이언트 애플리케이션의 리다이렉트 URI로 다시 리다이렉트한다. 이 때 인증 코드가 URI에 포함되어 전달된다.

5. 엑세스 토큰 요청: 클라이언트 애플리케이션은 인증 코드와 자신의 클라이언트 아이디, 시크릿, 그리고 리다이렉트 URI를 사용하여 인증 서버에게 엑세스 토큰을 요청한다.

6. 엑세스 토큰 발급: 인증 서버는 클라이언트 애플리케이션의 요청을 검증하고, 요청이 올바르면 엑세스 토큰을 발급한다. 이제 클라이언트 애플리케이션은 이 엑세스 토큰을 사용하여 리소스 서버에게 사용자 정보를 요청할 수 있다.

이 과정을 통해 Authorization Code 방식은 사용자의 자격증명이 클라이언트 애플리케이션에 노출되지 않도록 한다. 사용자의 로그인 정보는 오직 인증 서버에서만 처리되며, 클라이언트 애플리케이션은 인증 코드와 자신의 클라이언트 아이디 및 시크릿을 사용해 액세스 토큰을 얻을 수 있다.

이러한 방식은 사용자의 로그인 정보를 안전하게 보호하면서, 클라이언트 애플리케이션이 필요한 리소스에 접근하는 데 필요한 토큰을 얻을 수 있도록 한다. 이 방식은 웹 애플리케이션에서 가장 일반적으로 사용되는 인증 방식으로, 사용자의 정보를 안전하게 보호하는 데 중요한 역할을 한다.

Implicit Grant (암묵적 승인 방식)

Implicit Grant (암묵적 승인 방식) 인증 흐름은 주로 클라이언트 사이드 애플리케이션에서 사용된다. 클라이언트 사이드 애플리케이션은 웹 브라우저 등에서 직접 실행되는 애플리케이션을 말한다. 이 방식은 Authorization Code 흐름보다 간단하지만, 액세스 토큰이 클라이언트 사이드에 직접 노출되므로 보안상 문제가 있을 수 있다.

주요 단계

1. 사용자 인증 요청: 클라이언트 애플리케이션은 사용자를 인증 서버로 리다이렉트한다. 이 때 클라이언트 애플리케이션 식별자, 요청하는 접근 범위, 리다이렉트 URI 등의 정보를 포함한다.

2. 사용자 인증: 인증 서버는 사용자에게 로그인 페이지를 제공한다. 사용자는 이 페이지에서 자신의 자격증명을 입력하고 로그인한다. 이 정보는 클라이언트 애플리케이션에 전달되지 않는다.

3. 사용자 인가: 로그인이 성공하면 인증 서버는 사용자에게 클라이언트 애플리케이션이 요청하는 접근 범위에 대한 인가를 받는다.

4. 액세스 토큰 발급: 사용자가 인가를 승인하면, 인증 서버는 사용자를 클라이언트 애플리케이션의 리다이렉트 URI로 다시 리다이렉트한다. 이 때 액세스 토큰이 URI의 프래그먼트(#으로 시작하는 부분)에 포함되어 전달된다.

5. 리소스 요청: 클라이언트 애플리케이션은 이 액세스 토큰을 사용하여 리소스 서버에 사용자 정보를 요청할 수 있다.

이 방식은 서버 사이드에서 인증 코드를 교환하는 단계가 없기 때문에 상대적으로 빠르지만, 액세스 토큰이 브라우저를 통해 직접 전달되므로 CSRF(Cross-Site Request Forgery) 등의 공격에 취약할 수 있다. 그래서 가능한 한 보안을 강화하거나 다른 인증 흐름을 사용하는 것이 좋다.

Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)

Resource Owner Password Credentials Grant (자원 소유자 자격증명 승인 방식)은 사용자(리소스 소유자)의 ID와 비밀번호를 직접 사용하여 인증하는 방법이다. 일반적으로 이 방식은 신뢰할 수 있는 애플리케이션에서만 사용되어야 한다. 그 이유는 사용자의 비밀번호를 애플리케이션에 직접 제공해야 하기 때문이다.

주요 단계

1. 사용자 인증 요청: 클라이언트 애플리케이션은 사용자로부터 ID와 비밀번호를 직접 수집한다.

2. 액세스 토큰 요청: 클라이언트 애플리케이션은 수집한 사용자의 ID와 비밀번호를 사용하여 인증 서버에게 액세스 토큰을 요청한다. 이 때, 클라이언트 애플리케이션의 ID와 시크릿도 함께 전송되어 인증 서버는 이를 확인하여 요청의 유효성을 검증한다.

3. 액세스 토큰 발급: 인증 서버는 받은 사용자의 ID와 비밀번호를 확인하여 올바르다면 액세스 토큰을 발급한다. 이제 클라이언트 애플리케이션은 이 액세스 토큰을 사용하여 사용자를 대신하여 리소스 서버에 리소스 요청을 할 수 있다.

이 방식의 가장 큰 단점은 사용자의 비밀번호를 애플리케이션에 직접 제공해야 한다는 것이다. 따라서, 이 방식을 사용하는 애플리케이션은 반드시 사용자로부터 충분한 신뢰를 받아야 한다. 또한, 이 방식은 비밀번호 변경 등의 보안 조치가 취해져야 하는 상황에서 문제가 될 수 있다. 예를 들어, 비밀번호 정책 변경 등으로 인해 사용자의 비밀번호가 변경되면 애플리케이션은 다시 사용자의 변경된 비밀번호를 수집해야 한다.

Client Credentials Grant (클라이언트 자격증명 승인 방식)

Client Credentials Grant (클라이언트 자격증명 승인 방식)은 클라이언트 자체의 자격 증명을 사용하여 액세스 토큰을 얻는 방법이다. 이 방식은 클라이언트가 별도의 리소스 소유자의 동의나 인증 없이 서비스를 요청할 때 유용하며, 클라이언트가 서비스를 사용자를 대신하여 사용하는 경우에 주로 사용된다.

주요 단계

1. 액세스 토큰 요청: 클라이언트는 자신의 ID(클라이언트 아이디)와 비밀번호(클라이언트 시크릿)를 사용하여 인증 서버에게 액세스 토큰을 요청한다.

2. 액세스 토큰 발급: 인증 서버는 클라이언트의 자격 증명을 확인하고, 이를 통해 클라이언트의 요청이 유효함을 판단한다. 요청이 유효하다면 인증 서버는 액세스 토큰을 발급한다.

이 방식의 주요 장점은 별도의 사용자 인증 과정이 필요 없다는 것이다. 따라서 서비스 제공자와 사용자 간의 신뢰 관계가 미리 구축되어 있거나, 클라이언트 자체가 리소스 소유자인 경우에 이 방식을 사용할 수 있다.

하지만 이 방식의 주요 단점은 클라이언트가 아닌 사용자의 리소스에 대한 액세스 권한을 제공할 수 없다는 것이다. 즉, 이 방식은 클라이언트가 사용자를 대신해서 인증을 받아야 하는 상황에는 적합하지 않다. 따라서 이 방식은 클라이언트가 직접적으로 리소스를 소유하거나, 사용자의 개입이 필요 없는 서비스에서 주로 사용된다.

OAuth2.0 장점과 단점

---

장점

1. 보안: 사용자는 자신의 아이디와 비밀번호를 직접 공유하지 않고, 제 3자 애플리케이션에 서비스 접근 권한을 부여할 수 있다. 이는 사용자의 인증 정보를 보호하며, 제 3자 애플리케이션에게 필요한 최소한의 권한만 부여하는데 도움이 된다.

2. 유연성: OAuth 2.0은 다양한 유형의 애플리케이션(웹, 모바일, 서버)을 지원하며, 다양한 시나리오에 맞게 설정할 수 있다.

3. 사용자 경험: 사용자는 한 번 로그인하여 다른 서비스에서 자신의 정보를 사용할 수 있도록 허용하면, 해당 서비스에 다시 로그인할 필요가 없어진다. 이는 사용자 경험을 향상시키며, 사용자가 여러 서비스를 쉽게 이용할 수 있도록 한다.

단점

1. 복잡성: OAuth 2.0은 기술적으로 복잡한 프로토콜로, 구현이 어렵고 오류가 발생하기 쉽다. 따라서 적절한 보안 지침을 준수하고, 테스트와 유지 보수에 시간과 노력을 투자해야 한다.

2. 보안 취약점: 잘못 구현된 OAuth 2.0 시스템은 공격자가 인증 토큰을 가로채는 등의 보안 취약점을 가질 수 있다. 따라서 엄격한 보안 조치를 취해야 하며, 지속적인 보안 업데이트와 패치가 필요하다.

3. 중앙집중식: OAuth 2.0은 중앙 집중식 서비스에 의존적이다. 즉, 사용자가 신뢰하는 서비스(예: Google, Facebook 등)가 인증 과정을 처리한다. 이는 이러한 대형 서비스들이 사용자 데이터에 대한 엄청난 통제력을 가지게 되는 문제를 야기할 수 있다.