OAuth이란?

OAuth 이란?

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

OAuth 2.0은 승인을 위한 업계 표준 프로토콜이다. OAuth 2.0은 웹 애플리케이션, 데스크톱 애플리케이션, 기타 장치에 대한 특정 인증 권한을 제공하면서 클라이언트 개발자 작업을 단순화시켜준다.

OAuth는 인증 정보를 제공하는 웹사이트(서비스 제공자)와 이 정보를 이용하려는 웹사이트나 앱(클라이언트) 사이의 인증을 관리한다. 클라이언트는 사용자 인증 정보를 직접 수집하지 않으며, 대신 서비스 제공자로부터 인증 정보를 가져와 클라이언트가 이를 사용할 수 있도록 한다.

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증 방식인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조일 가능성이 매우 많다. 기본 인증 방식이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인하였다. 예를 들면 구글의 AuthSub, AOL의 OpenAuth, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있다. OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 이용하면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합하여 사용하는 것이 가능하게 된다.

예를들어 Facebook, kakao, naver, Google 등의 외부 소셜 계정을 기반으로 간편하게 회원가입 및 로그인할 수 있다. 클릭 한번으로 간편하게 로그인할 수 있을 뿐만 아니라 연동되는 외부 웹 어플리케이션에서 Facebook, kakao, Naver, Google 등이 제공하는 기능을 간편하게 사용할 수 있다는 장점이 있다.
예로 naver로 로그인하면 API를 통해 연동된 계정의 캘린더, 연락처, 쇼핑내역을 가져와 사용자에게 보여줄 수 있다. 이때 사용되는 프로토콜이 OAuth이다.

즉, 우리의 서비스가 우리 서비스를 이용하는 유저의 타사 플랫폼 정보에 접근하기 위해서 권한을 타사 플랫폼으로부터 위임 받는 것 이다.

---

OAuth 2.0 주체

OAuth 2.0은 일반적으로 다음과 같은 네 가지(Resource Owner, Authorization Server, Resource Server, Client) 주체를 갖고있다.

Resource Owner

리소스 소유자. 우리의 서비스를 이용하면서, 구글, 페이스북 등의 플랫폼에서 리소스를 소유하고 있는 사용자이다. 리소스라 하면 '구글 캘린더 정보', '페이스북 친구 목록', '네이버 블로그 포스트 작성' 등이 해당될 것이다.

Authorization Server & Resource Server

Authorization Server는 Resource Owner를 인증하고, Client에게 액세스 토큰을 발급해주는 서버이다. Resource Server는 구글, 페이스북, 트위터와 같이 리소스를 가지고 있는 서버를 말한다.

Authorization Server와 Resource Server는 공식문서상 구분되어 있는데, 별개의 서버로 구성할지 하나의 서버로 구성할지는 개발자가 판단해서 개발한다고 한다.

Client

Resource Server의 자원을 이용하고자 하는 서비스.  우리가 개발하거나 사용하려는 서비스(리소스를 요청해 사용하는 서비스)로 생각하면 된다.

Client는 우리가 구현하는 서비스이므로 Resource Owner와 헷갈리지 말자. Resource Server와 Authorization Server의 입장에서는 우리 서비스가 클라이언트이기 때문에 이런 이름을 갖게 된 것 이다.

OAuth 2.0의 4가지 역할

구분	설명
Client	보호된 자원을 사용하려고 접근 요청을 하는 애플리케이션
Resource Owner	웹 서비스를 이용하려는 유저, 자원(개인정보)을 소유하는 자, 사용자
Resource Server	사용자의 보호된 자원을 호스팅하는 서버
Authorization Server	권한을 부여(인증에 사용할 아이템 제공)하는 서버 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 Acces Token을 발급하여 권한을 부여하는 역할

OAuth 2.0 주요 용어

구분	설명
Authentication	인증, 접근 자격이 있는지 검증하는 단계
Authorization	인가, 자원에 접근할 권한을 부여하는 것입니다. 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여
Access Token	리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token입니다.
Refresh Token	Access Token은 보안상 만료기간이 짧기 때문에 얼마 지나지 않아 만료되면 사용자는 다시 로그인을 시도해야 하지만 Refresh Token이 있으면 Access Token이 만료될때, Refresh Token을 통해서 Access Token을 재발급 받아서 다시 로그인할 필요가 없게 됨

---

OAuth 2.0 4가지 주요 프로토콜

OAuth 2.0 프로토콜에서는 다양한 클라이언트 환경에 적합하도록 권한 부여 방식에 따른 프로토콜을 4가지 종류(Authorization Code Grant, Implicit Grant, Resource Owner Password Credentials Grant, Client Credentials Grant)로 구분하여 제공하고 있다. 

1. Authorization Code Grant(인증 코드 부여): 이 프로토콜은 클라이언트 애플리케이션이 사용자를 대신하여 보호된 리소스에 액세스해야 할 때 사용된다. 사용자는 먼저 보호된 리소스에 액세스할 수 있는 클라이언트 응용 프로그램 권한을 인증하고 부여할 수 있는 권한 부여 서버로 리디렉션된다. 그런 다음 권한 부여 서버는 보호된 자원에 액세스하기 위한 액세스 토큰을 얻는 데 사용되는 권한 부여 코드를 클라이언트 애플리케이션에 발행한다.
2. Implicit Grant Type(암묵적 승인 방식): 이 프로토콜은 Authorization Code Grant Type과 유사하지만 클라이언트 애플리케이션이 웹 브라우저 기반 JavaScript 애플리케이션과 같이 클라이언트 비밀을 기밀로 유지할 수 없을 때 사용된다. 이 프로토콜에서 액세스 토큰은 인증 코드를 발행하지 않고 클라이언트 응용 프로그램에 직접 반환한다.
3. Resource Owner Password Credentials Grant Type(리소스 소유자 암호 자격 증명 부여): 이 프로토콜은 클라이언트 응용 프로그램이 이미 사용자의 사용자 이름과 암호를 가지고 있고 이를 액세스 토큰으로 직접 교환하려는 경우에 사용한다. 이 프로토콜은 클라이언트 응용 프로그램이 사용자 암호에 액세스할 수 있으므로 공용 응용 프로그램에는 권장되지 않는다.
4. Client Credentials Grant Type(클라이언트 자격 증명 부여): 이 프로토콜은 클라이언트 애플리케이션이 사용자를 대신하여 보호된 리소스에 액세스하지 않고 자체 리소스에 액세스하려는 경우에 사용한다. 클라이언트 애플리케이션은 자체 클라이언트 ID와 클라이언트 시크릿을 직접 교환하여 자체 리소스에 액세스할 수 있는 액세스 토큰을 얻을 수 있다.

이 네 가지 프로토콜은 OAuth 2.0의 주요 프로토콜이며 각 프로토콜은 서로 다른 시나리오에 사용된다. Authorization Code Grant Type은 대부분의 사용 사례에 적합하며, Implicit Grant Type은 클라이언트 시크릿을 유지할 수 없는 경우에. Resource Owner Password Credentials Grant Type은 사용자의 비밀번호를 직접 교환하는 경우에만 사용해야 하며, Client Credentials Grant Type은 자체 리소스에 액세스하는 경우에만 사용한다.

---

OAuth2.0의 동작 방식

Authorization Code Grant (권한 부여 승인 코드 방식)을 기준으로 동작방식을 알아보자

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식이다. 간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식이다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용된다. Refresh Token의 사용이 가능한 방식이다.

Refresh Token (리프레시 토큰)을 사용 액세스 토큰을 받아오는 방식은 매번 액세스 토큰을 발급받지 않아도 되기 때문에 사용자 경험이 더 좋아진다.

 

@inpa.tistory.  OAuth 2.0 개념 정리

권한 부여 승인 요청 시 response_type을 code로 지정하여 요청한다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력한다. 이 페이지를 통해 사용자가 로그인을 하면 권한 서버는 권한 부여 승인 코드 요청 시 전달받은 redirect_url로 Authorization Code를 전달한다. Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환된다.

권한 부여 승인 코드 방식 흐름

사용자는 클라이언트 웹사이트 또는 애플리케이션에서 로그인 버튼이나 링크를 클릭하여 인증 요청을 시작.

클라이언트는 사용자를 인증 서버의 인증 엔드포인트로 리디렉션한다. 클라이언트 ID, 리디렉션 URI, 요청 범위, 응답 유형을 "code"로 설정하고 필요한 경우 상태 매개변수를 포함한다.

인증 서버는 사용자를 인증하고 요청된 리소스에 대한 액세스 권한 부여에 대한 동의를 요청한다. 사용자가 액세스를 거부하면 인증 서버는 오류 메시지와 함께 사용자를 클라이언트로 다시 리디렉션한다.

사용자가 액세스를 승인하면 인증 서버는 쿼리 문자열에 인증 코드를 포함하여 사용자를 클라이언트로 다시 리디렉션한다.

클라이언트는 인증 코드, 클라이언트 ID, 클라이언트 암호 및 리디렉션 URI를 사용하여 인증 서버의 토큰 엔드포인트에 POST 요청을 보낸다.

인증 서버는 인증 코드, 클라이언트 ID 및 클라이언트 비밀을 확인하고 Access 토큰 및 Refresh 토큰을 발급한다.

인증 서버는 Access 토큰 및 Refresh 토큰을 클라이언트에 반환한다.

클라이언트는 이제 Access 토큰을 사용하여 요청된 리소스에 액세스할 수 있다. Access 토큰이 만료된 경우 클라이언트는 사용자의 재인증 없이 Refresh 토큰을 사용하여 새 Access 토큰을 얻을 수 있다.

---

OAuth의 사용의 장단점

장점:

1. 보안측면: OAuth는 사용자가 로그인 자격 증명을 공유하지 않고 제3자 애플리케이션에 액세스 권한을 부여할 수 있도록하여 사용자의 중요한 정보를 안전하게 유지할 수 있다.
2. 사용자 제어: 사용자는 제3자 애플리케이션이 액세스할 수 있는 범위를 완전히 제어할 수 있으며 필요에 따라 언제든지 액세스 권한을 취소할 수 있다.
3. 사용자 경험: OAuth는 사용자가 사용하는 모든 웹 사이트 또는 애플리케이션마다 별도의 로그인 자격 증명을 생성할 필요가 없게 해준다.
4. 상호 운용성: OAuth는 다른 애플리케이션과 서비스가 원활하게 작동하도록하여 통합된 사용자 경험을 제공해준다.

단점:

1. 악용 가능성: 사용자가 악성 또는 제대로 설계되지 않은 제3자 애플리케이션에 액세스 권한을 부여하면 데이터가 위험에 빠질 수 있다.
2. 공급자에 대한 의존성: OAuth는 자체 보안 또는 안정성 문제가 있을 수 있는 타사 인증 공급자에 의존해야 한다.

---

https://www.oauth.com/  

OAuth.com - OAuth 2.0 Simplified

https://oauth.net/

OAuth Community Site

inpa Dev

[WEB] 📚 OAuth 2.0 개념 정리 (그림으로 이해하기 쉽게)