Oauth (Open Authorization)

Oauth는 타사 서비스 간에 인증을 제공하는 것에 대한 표준 프로토콜이다.
Open Authorization의 축약어다.

쉬운 예를 들자면, 대표적으로 SNS 로그인 같은 외부 로그인 구조가 Oauth 구조를 따르는 시스템 형태 중 하나다.

Oauth가 생겨나게 된 배경, 발전사와 그 구조에 대해서 간략하게 다뤄보겠다.

Oauth의 등장 배경

예전에는 서비스 간 연동이 필요할 경우 매우 무식하고 과격한 방법으로 해결을 했었다.

예를 들어, 내가 만드는 서비스에서 트위터의 사용자 정보를 가져올 필요가 있다고 가정해보자.
그럼 그냥 사용자에게 트위터의 ID:Password를 내 서비스에 입력하도록 한 다음에 그걸 받고 로그인을 해서 처리한 것이다.

당연히 이 방식은 보안적으로도, 사용자 편의성 수준에서도 매우 끔찍한 방법이다.

이 방식에 대한 문제를 심각하게 인지한 시점은, 2006년, 트위터였다.
Ma.gnolia라는 서비스에서 트위터의 사용자 정보를 연동해서 자사 서비스에 활용하려고 했는데, 패스워드를 받아서 처리하는 좀 아니다 싶어서 표준안을 만들어보자는 이야기가 나온 것이다.

그렇게 해서 트위터의 주도로 나온 것이 OAuth라는 표준 프로토콜이다.

OAuth 핵심 원리

OAuth의 핵심 근간은 패스워드를 노출하지 않은 채로 타사가 데이터에 접근해야 한다는 것이다.

근데 도대체 어떻게 하면 타사가 패스워드 없이 인증시스템을 사용할 수 있을까?
패스워드든 토큰이든, 뭔가의 인증 수단을 전달받지 못한다면 신뢰 가능한 형태로 시스템을 구성하는 것은 불가능한 일이다.

그래서 나온 해결책은... 그냥 추가로 임시 패스워드를 만들어서 이런 용도로만 쓸 수 있게 하자는 것이었다.
기존 패스워드에 비해서 수명이 짧고, 일회성이고, 접근 범위 등을 제한할 수 있다는게 다를 뿐이다.

OAuth flow는 대략 다음과 같은 구조로 구현된다.

먼저 최종 유저에게 트위터 로그인창을 띄우고, 사용자 정보를 넘길 수 있다는 것도 동의를 받는다.

동의가 완료되면,

트위터가 연동을 위한 일종의 "임시 토큰"을 발급해준다.
이 임시 토큰의 공식 용어는 인가 코드(authorization code)다.

이 임시 토큰은 대체로 한번 쓰면 즉시 만료되며, 쓰지 않더라도 몇분 정도면 만료되게 만들어져있다.

그러면 타사 서비스는 인가 코드를 가져다가 다시 제대로 쓸 수 있는 "액세스 토큰"을 발급받는다.
이 "액세스 토큰"이 있다면 이제 타사 서비스는 이걸 가져다가 사용자의 정보를 조회할 수 있다.

이를 통해서 사용자의 영구 패스워드를 받지 않고도, 비교적 유연하고 안전한 형태로 사용자 정보에 접근할 수 있는 것이다.

하나로 정리된 그림

참고로 액세스토큰으로 사용자 정보를 조회하는 것은 OAuth 명세에는 포함되지 않는다.
그건 OpenID의 영역이다.

토큰과 만료

이 보안 시스템의 핵심은 만료다.
토큰(패스워드)가 유출되더라도 수명이 존재한다면 악용을 당할 가능성이 현저히 줄어들기 때문이다.

OAuth에는 수명이 다른 총 3가지의 토큰이 존재한다. 이 계층화를 통해서 공격 가능한 지점을 최소화하는 것이다.

1. authorization code
authorization code는 위에서 언급했듯이, 최초 연동에 사용되는 임시 연동 토큰이다.
보통 리디렉션을 통해서 타사 서비스에 전달하곤 한다.
대체로 5분-10분 정도의 짧은 수명을 가지는 것이 특징이며, 한번 사용하면 즉시 만료되어야 한다.

**2. access token **
이것도 임시 패스워드의 일종이다. 이게 있으면 타사 서비스는 API에 토큰을 담고 사용해서 해당 User의 정보를 조회할 수 있다.
이건 수명을 가져야 하며, 수명이 다할때까지는 반복적으로 사용이 가능하다.
수명은 딱 정해져있진 않은데, 대체로 한시간 정도가 일반적이다.

그러면 access token이 만료되면 어떻게 해야할까?
그때마다 사용자에게서 새로 인가 코드를 받는 것도 방법이긴 한데, 그걸로는 한계가 있다. 그럴때 필요한 것이 refresh token이다.

3. refresh token (optional)
refresh token은 access token을 발급할 수 있는 상위 개념의 패스워드다.
access token보다 수명이 길며, 보통 한달에서 1년 정도를 만료 기한으로 잡는다.
refresh token의 수명을 늘리게 할지는 선택이다.
참고로 이건 OAuth의 필수 스펙은 아니다. 없는 것들도 있다.

Oauth 1 (2007)

Oauth 1은 2007년에 만들어진 최초 버전이다. 현재는 보안 취약점이 다양하게 많이 지적돼서 폐기된 상태다.
현 시점에서 Oauth 1를 지원하는 provider는 사실상 없다.

문제

• Access Token의 만료 기한이 스펙에 명시되지 않았다. (만료가 의무가 아니었음)
• 기능 자체도 확장성이 다소 떨어졌고, 매번 요청마다 서명을 포함하는 것이라서 구현 복잡도가 높았다.
• Session Fixation 취약점이 존재했다. (패치 버전 OAuth 1.0a에서 해결되긴 함)

Oauth 2 (2012)

그래서 우여곡절 끝에 OAuth 2를 다시 만들었다.
현 시점에서는 완연한 표준이고, 대부분의 provider들은 OAuth 2 표준에 맞춰서 서비스를 제공하고 있다.

개선

• 이전에 존재했던 많은 취약점을 개선했다.
• HTTPS가 필수이기 때문에 복잡하게 서명 처리하며 트래픽 횡령을 걱정할 필요가 사라졌다. 서명이 제거되어서 구현 구조가 간단해졌다.
• 단순한 토큰 기반으로만 상호작용할 수 있게 정의했기 때문에, 구현이 단순하고 확장이 자유롭다. OpenID Connect라는 통합 레이어도 이 덕분에 나온 것이다.

OpenID Connect

현 시점에서는 OAuth2 단독으로 사용하지는 않고, ID Token 개념을 덧댄 OIDC라는 설계 구조를 대부분 채택한다. 포함관계라서 달라질건 별로 없긴 하다.

상세한 내용은 별도 포스트를 참조한다.
https://blog.naver.com/sssang97/224084290003

참조
https://oauth.net/2/
https://www.upguard.com/blog/oauth