OAuth란?

SNS 로그인 API를 구현하거나 구글 쪽 API를 구현하다 보면 OAuth라는 키워드를 매우 자주 보게 된다.

예전에는 공부하느라 만들기 급급해서 알아보지도 않고 넘겼지만, 이제는 정확히 알고 있어야 할 것 같아서 공부하고 포스팅하려 한다.

먼저 OAuth에 대해 위키백과에서 말하는 내용은 아래와 같다.

 

https://ko.wikipedia.org/wiki/OAuth

OAuth - 위키백과, 우리 모두의 백과사전

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹 사이트 상의 자신들의 정보에 대해 웹 사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는 접근 위임을 위한 개방형 표준이다. 이 매커니즘은 여러 기업들에 의해 사용되는데 이를테면 아마존, 구글, 페이스북, 마이크로소프트, 트위터가 있으며 사용자들이 타사 애플리케이션이나 웹 사이트의 계정에 관한 정보를 공유할 수 있게 허용한다
OAuth가 쓰이기 전에는 인증방식의 표준이 없었기 때문에 기존의 기본 인증인 아이디, 비밀번호를 썼는데 이는 보안상 취약한 구조다. 기본 인증이 아닐 경우는 각 애플리케이션들이 각자의 개발한 회사의 방법대로 사용자를 확인했다. OAuth는 이렇게 제각각인 인증방식을 표준화한 인증방식이다. OAuth를 쓰면 이 인증을 공유하는 애플리케이션끼리는 별도의 인증이 필요없다. 따라서 여러 애플리케이션을 통합해 쓰는 게 가능해진다.

 

https://en.wikipedia.org/wiki/OAuth

OAuth - Wikipedia

OAuth(Open Authorization)는 액세스 위임을 위한 공개 표준으로, 일반적으로 인터넷 사용자가 웹 사이트나 애플리케이션에 암호를 제공하지 않고 다른 웹 사이트의 정보에 대한 접근 권한을 부여하는 방법으로 쓰인다. 이 매커니즘은 아마존, 구글, 페이스북, 마이크로소프트, 트위터 같은 회사에서 사용자가 자신의 계정에 대한 정보를 타사 애플리케이션 또는 웹 사이트와 공유할 수 있도록 하는 데 사용한다
일반적으로 OAuth는 리소스 소유자를 대신해 서버 리소스에 대한 보안 위임 액세스를 클라이언트에 제공한다. 리소스 소유자가 자격 증명을 제공하지 않고 서버 리소스에 대한 타사 액세스 권한을 부여하는 프로세스를 지정한다. HTTP와 함께 작동하도록 설계된 OAuth는 기본적으로 리소스 소유자의 승인을 받아 권한 부여 서버에서 액세스 토큰을 타사 클라이언트에 발급할 수 있게 한다. 그러면 제3자는 액세스 토큰을 사용해 리소스 서버에서 호스팅하는 보호된 리소스에 접근한다. 특히 OAuth 2.0은 웹 앱, 데스크톱 앱, 핸드폰, 스마트 기기에 대한 특정 권한 부여 흐름을 제공한다

 

정리하면 아이디, 비밀번호 대신 사용자에게 액세스 토큰을 부여해서 사용자가 이 토큰을 통해 서버 리소스에 접근할 수 있게 하는 인증 방식이란 것 같다.

다른 사람들은 뭐라고 하는지 좀 더 찾아봤다.

 

https://www.varonis.com/blog/what-is-oauth/

What is OAuth? Definition and How it Works

OAuth는 애플리케이션에 보안 지정 접근 기능을 제공하는 개방형 표준 인증 프로토콜 또는 프레임워크다. 예를 들어 ESPN에게 페이스북 비밀번호를 주지 않고도 ESPN.com이 회원의 프로필에 접근하거나 타임라인에 업데이트를 게시하는 건 괜찮다고 페이스북에 알릴 수 있다. 이것은 주요 방식으로 위험을 최소화한다. ESPN이 침해당하는 경우 페이스북 비밀번호는 안전하게 유지된다. OAuth는 비밀번호 데이터를 공유하지 않고 대신 인증 토큰을 써서 소비자와 서비스 제공자 간의 신원을 증명한다. OAuth는 비밀번호를 알려주지 않고 다른 앱과 상호작용하는 애플리케이션을 승인할 수 있는 인증 프로토콜이다

 

https://auth0.com/intro-to-iam/what-is-oauth-2/

What is OAuth 2.0 and what does it do for you? - Auth0

...(중략) OAuth 2.0은 권한 부여 프로토콜이다. 따라서 주로 원격 API 또는 사용자 데이터 같은 리소스 집합에 대한 접근 권한을 부여하는 수단으로 설계됐다. OAuth 2.0은 액세스 토큰을 사용한다. 액세스 토큰은 최종 사용자를 대신해 리소스에 접근할 수 있는 권한을 나타내는 데이터 조각이다. OAuth 2.0은 액세스 토큰에 대한 특정 형식을 정의하지 않는다. 그러나 일부 컨텍스트에선 JWT 형식이 자주 사용된다. 이를 통해 토큰 발급자는 토큰 자체에 데이터를 포함할 수 있다. 또는 보안상 이유로 액세스 토큰에는 만료일이 있을 수 있다

 

https://www.hp.com/us-en/shop/tech-takes/what-is-oauth

OAuth는 암호를 노출하지 않고 서비스 간 정보를 공유할 수 있도록 하는 기술 표준이다. 웹 사이트 및 앱 개발자가 쓰는 널리 채택된 표준이다. OAuth는 어떻게 작동하며 개인정보를 어떻게 보호하는가?

현대에는 많은 디지털 계정이 있다. 소셜 미디어 계정, 온라인 은행 계좌, 기업 및 소매업체의 온라인 계정, 즐겨 찾는 웹 사이트의 계정 등이 있다. 이런 모든 디지털 계정을 쓰려면 사용자 이름, 암호를 설정해야 한다. 현대 사회의 또 다른 측면은 많은 온라인 서비스가 통합돼 있다는 것이다. 예를 들어 스마트폰이 있으면 페이스북에 사진을 게시하거나 트위터에서 좋은 블로그 게시글을 공유할 수 있다. 오늘날 모든 온라인 서비스는 다른 인터페이스와 상호작용하도록 설계된 것처럼 보인다. 데이터 공유를 활성화하면 제3자에게 개인정보에 대한 접근 권한을 부여하게 된다. 계정을 연결하면 안 된다는 뜻이 아니다. OAuth와 같은 표준은 제3자 간에 데이터를 전송하는 동안 개인정보를 안전하게 보호한다

어느 서비스가 다른 서비스에 있는 정보를 쓰려면 어떻게 할까? 인스타그램 사진 중 하나를 페이스북에 공유하려 한다고 가정한다. 페이스북이 인스타그램에 게시된 사진을 검색할 수 있게 인스타그램 비밀번호를 요청할 것이라 생각할 것이다. 하지만 위험하다. 비밀번호를 많이 알려줄수록 비밀번호가 손상될 가능성이 높아진다. 여기서 OAuth가 등장한다. OAuth는 "Open Authorization"의 약자로 내가 비밀번호를 알려주지 않고도 제3자 서비스가 귀하의 정보를 교환할 수 있게 한다

 

OAuth를 사용하는 서비스는 사용자에게 액세스 토큰을 주는데 이 토큰은 JWT 형식일 수도 있다.

이 액세스 토큰을 받은 사용자는 자신의 개인정보를 서비스에 넘기지 않고도 그 서비스에 회원가입 or 로그인해서 서비스를 이용할 수 있다.

해외에선 구글, 페이스북, 트위터 등의 기업들이 OAuth를 사용 중이고 국내에선 네이버, 카카오 등이 OAuth를 통해 자사 서비스를 이용하게 한다. 대표적인 게 로그인 API다.

 

그래서 어찌저찌 액세스 토큰을 발급받았다고 가정한다. 위의 글을 보면 보안상 이유로 액세스 토큰엔 만료일이 있을 수 있다고 한다. 이 액세스 토큰이 만료되면 더 이상 쓸 수 없을텐데 그 때는 어떻게 해야 할까?

이걸 위해서 만들어진 것이 리프레시 토큰(Refresh Token)이다.

 

https://www.ibm.com/docs/en/api-connect/10.0.1.x?topic=tokens-refresh 

OAuth 인증을 쓰는 경우 리프레시 토큰을 활성화할 수 있다. 현재 액세스 토큰이 유효하지 않거나 만료될 때 새 액세스 토큰을 얻거나 동일 또는 더 좁은 범위의 추가 액세스 토큰을 얻기 위해 리프레시 토큰이 클라이언트에 발급된다. OAuth 인증을 쓰는 경우 API 요청은 Authorization HTTP 헤더를 써서 유효한 액세스 토큰을 포함해야 한다.

 

 

 

위 이미지는 만료된 액세스 토큰을 새로고침하는 과정을 보여준다.

이를 좀 더 간단한 그림으로 표현하면 아래와 같다.

 

https://tansfil.tistory.com/59

 

액세스 토큰은 리프레시 토큰에 비해 일반적으로 유효기간이 짧다. 그래서 사용자가 액세스 토큰을 발급받아 서비스를 이용하다가 이 액세스 토큰이 만료됐을 경우, 액세스 토큰과 같이 발급받은 리프레시 토큰을 이용해 액세스 토큰을 새로 발급받는다. 그럼 사용자는 계속해서 서비스를 이용할 수 있다.

 

2번째 그림에선 이해를 위해 사용자와 서버가 있는 형태를 취했지만, 원래 OAuth의 참여자는 4개로 구분된다.

 

1. Resource Server : API 서버를 말하는 OAuth 2.0 용어. 앱이 액세스 토큰을 얻은 후 인증된 요청을 처리한다. 일반적으로 이런 액세스 요청 처리를 위한 CRUD API를 제공하며, 클라이언트에 리소스를 제공하기 전에 액세스 토큰을 검사해 액세스 권한을 부여해야 하는지를 결정한다.
2. Resource Owner : 앱이 자기 계정에 접근하게 승인하는 사용자. 사용자 계정에 대한 앱의 액세스는 부여된 권한 범위로 제한된다
3. Client : Resource Server에 접속해 자원을 가져와 사용하는 클라이언트. 웹 앱 또는 애플리케이션일 수 있다. 쉽게 말해 내가 만들고 있는 앱일 수도 있다.
4. Authorization Server : 사용자 동의를 받아 권한을 부여하는 인증 서버. 클라이언트의 접근 자격을 확인하고 액세스 토큰을 발급해 권한을 부여한다

 

이 4개 참여자들의 상호작용으로 사용자를 인증해 서비스를 이용할 수 있게 하는 게 OAuth의 기본 흐름이다.