OAuth

OAuth

Open Authorization의 약자이다. 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로써 사용되는, 접근 위임을 위한 개방형 표준이다.
이 매커니즘은 여러 기업들에 의해 사용되고 있다.(페이스북, 카카오, 구글 등등)

---

OAuth가 사용되기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본인증인 아이디와 비밀번호를 사용하였는데, 이는 보안상 취약한 구조일 가능성이 매우 많다.

기본 인증이 아닐 경우는 각 애플리케이션들의 각자의 개발한 회사의 방법대로 사용자를 확인하였다. 예로는 구글의 AuthSub, 야후의 BBAuth, 아마존의 웹서비스 API 등이 있다.

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

 

역사

1. OAuth 1.0

• RFC 5849: The OAuth 1.0 Protocol 에 정의되어있다
• 세션 고정 공격 (a session fixation attack)에 취약점이 발견되어 1.0a 개정판이 나오게 되었다

2. OAuth 1.0 Revision A

• 1.0 spec의 세션 고정 공격을 해결하기 위해 만들어짐
• 1.0a 개정판을 만들었는데 2.0 인증 프레임워크가 나와 폐기됨;;;

3. OAuth 2.0

• RFC 6749 : The OAuth 2.0 Authorization Framework에 정의
• 혼합 공격(Mix-Up Attack)에 취약점 발견
• 많은 패치와 확장을 거쳐서 현재에 이르러 있다

4. OAuth 2.1 (in-progress)

• 이름은 어떻게 바뀔지 모르지만 현재는 2.1로 IETF에서 이야기 중
• 모든 인증 코드 부여에 대해 PKCE가 필요하다는 게 중요 포인트
• legacy 들은 버릴 예정 (Implicit, Password Credentials )
• (2021. 12 기준) 아직 모든 게 미정이지만, 계속 발전하는 중이라는 것

 

OAuth 구성(1.0)

3-legged-auth

유저(user), 컨슈머(consumer), 서비스 프로바이더(service provider)

하지만 OAuth 1.0은 구현이 복잡하고 웹이 아닌 애플리케이션에서의 지원이 부족했다. HMAC을 통해 암호화를 하는 번거로운 과정을 겪는다. 또한 인증토큰이 만료되지 않는 점이 있었다.

그래서 나온 게 OAuth 2.0이다.

 

 

OAuth 1.0과 2.0의 차이

1. 단순성과 확장
   OAuth 1.0 은 비교적 복잡한 서명 및 암호화 기술을 사용하여 인증을 처리했다. 반면에 OAuth 2.0 은 단순화되고 더 확장 가능한 프로토콜로서, 개발자들이 더 쉽게 구현하고 사용할 수 있도록 설계되었다.
2. 토큰의 사용
   OAuth 1.0에서는 액세스 토큰과 비밀 토큰을 사용하여 인증을 처리했다. 반면에 OAuth 2.0에서는 액세스 토큰과 리프레시 토큰을 사용하여 보다 간편하고 유연한 인증 방식을 제공한다.
3. 보안
   OAuth 1.0 은 서명된 요청을 통해 보안을 유지하였지만, OAuth 2.0 은 HTTPS를 통해 보안을 제공하며, 토큰 자체의 보안성에 초점을 두고 있다.
4. 범용성
   OAuth 2.0 은 다양한 플랫폼 및 애플리케이션에 적용하기 위해 설계되었다. OAuth 1.0 은 주로 웹 기반 애플리케이션에 사용되었다.

따라서, OAuth 2.0 은 보다 단순하고 확장 가능한 프로토콜로서, OAuth 1.0의 한계를 극복하고 다양한 환경에서 더 널리 사용되고 있다.

OAuth 2.0 구성

현재 우리가 쓰는 OAuth는 2.0에 해당한다  어떤 방식으로 구성되어 있는지 알아보자.

 

OAuth 2.0에서 정의하는 4가지 역할

1) Resource Owner(사용자)
사용자이자 리소스 소유자. 리소스의 접근을 허가해 준다.
2) Client(애플리케이션)
Resource Owner를 대신하여 권한을 부여하고 보호된 리소스를 Resource Server에 요청하는 애플리케이션이다.
3) Resource Server(API 서버)
보호받는 리소스를 호스팅 한다. 액세스 토큰을 발급받은 클라이언트의 요청을 수락하고 응답할 수 있는 서버이다.
4) Authroization Server(인증 서버)
Resource Owner 인증을 통해 클라이언트에 액세스 토큰을 발급해 주는 서버이다.


Authorization Server와 Resource Server는 구성에 따라 아키텍처가 달라질 수도 있다. Authorization Server와 Resource Server가 동일한 서버일 수도 있고 별개로 동작할 수도 있다. 또는 하나의 Authorization Server가 여러 Resource Server에 액세스 토큰을 발급할 수도 있다.

권한 부여 방식

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

 

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

 

2. Implicit Grant │ 암묵적 승인 방식

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript 등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식이다.

Refresh Token 사용이 불가능한 방식이며, 이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않는다. Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달된다는 단점이 있다.

 

 

권한 부여 승인 요청 시 response_type을 token으로 설정하여 요청한다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력하게 되며 로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달한다.

 

3. Resource Owner Password Credentials Grant │ 자원 소유자 자격증명 승인 방식

간단하게 username, password로 Access Token을 받는 방식이다.

클라이언트가 타사의 외부 프로그램일 경우에는 이 방식을 적용하면 안 된다. 자신의 서비스에서 제공하는 애플리케이션일 경우에만 사용되는 인증 방식이다. Refresh Token의 사용도 가능하다.

 

 

위와 같이 흐름은 간단하다. 제공하는 API를 통해 username, password을 전달하여 Access Token을 받는 것이다. 중요한 점은 이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식이라는 점이다.

 

4. Client Credentials Grant │ 클라이언트 자격증명 승인 방식

클라이언트의 자격증명만으로 Access Token을 획득하는 방식이다.

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용된다. 이 방식은 자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없다.

 

 

OAuth 2.0의 활용 사례

1. 소셜 미디어 로그인
   OAuth는 사용자가 소셜 미디어(페이스북, 구글, 카카오톡)의 계정을 사용하여 다른 애플리케이션에 로그인할 수 있도록 하여 사용자는 새로운 계정을 만들거나 기존 계정으로 로그인하는 번거로움 없이 애플리케이션에 접근할 수 있다.
2. API 인증 및 권한 부여
   OAuth는 애플리케이션이 외부 서비스의 API를 안전하게 사용하고 권한을 관리할 수 있도록 한다. 예를 들어, 애플리케이션이 사용자의 이메일 정보에 접근하려면 OAuth를 사용하여 해당 사용자의 동의를 받고 인증 및 권한 부여를 수행할 수 있다.
3. 단일 로그인(SSO)
   OAuth는 여러 애플리케이션 간에 단일 로그인(SSO)을 구현하는 데 사용될 수 있다. 사용자는 하나의 인증과정으로 여러 애플리케이션에 접근할 수 있으며, 이를 통해 사용자 경험을 향상시킬 수 있다.
4. 마이크로서비스 아키텍처
   OAuth는 마이크로서비스 아키텍처에서 서비스 간의 신뢰성 있는 통신을 위해 사용될 수 있다. 각 서비스는 OAuth를 통해 인증된 요청을 처리하고 권한을 확인하여 보안을 유지할 수 있다.
5. IoT 기기 인증
   OAuth는 인터넷의 사물들이 상호작용할 수 있도록 인증과 권한 부여를 제공할 수 있다. 예를 들어, 스마트 홈 기기는 OAuth를 사용하여 사용자의 인증 정보를 받고 해당 사용자의 권한에 따라 동작할 수 있다.

참조:
https://ko.wikipedia.org/wiki/OAuth
https://www.ssemi.net/what-is-the-oauth2/
https://charming-kyu.tistory.com/36