Oauth의 등장 배경과, 변화 과정에 대해 알아보자

Oauth는 왜 나왔을까??

Oauth 이전 방식으로 서비스를 접근하려면?

바로 위와 같은 상황을 해결하기 위해서 Oauth 가 등장했는데요

그전까지는 API Access Deligation 이 있었다고 하는데요

회사마다 모두 다른 정책을 사용했기에, 웹 표준이 없어서 회사마다 다른 정책을 구현해야 했다고 합니다

이를 처음 비공식적으로 2006 년에 합의해서 나온 것이 Oauth1.0이고,

이후 보안 문제를 해결해서 나온 것이 Oauth1.0a입니다

Oauth 사용 방식의 변화

처음 oauth의 목적

위에 나왔던 것처럼 권한 부여에 목적을 가지고 등장한 프로토콜인데요

사용자의 ID와 패스워드를 타 서비스에 제공하지 않고, 구글캘린더 같은 기능을 사용할 수 있도록 하려고 했습니다

구글 캘린더 외에 Gmail 같은 서비스에 접근하는 것은 허가하지 않는 인가(Authorization)를 위한 것입니다

인증을 위한 Oauth의 사용

Oauth 를 인증(Authentication)의 목적으로 사용하기 시작

사용자들의 불편함을 해결하기 위해, 어느 순간부터 Oauth를 인가(Authorization) 이 아닌 인증(Authentication)을 위해 사용하는데요

ID, 패스워드를 관리하기 힘들다는 부분도 한몫을 하긴 했습니다

최소한의 사용자 식별이 필요할 때, 직접 가입을 만드는 대신, Oauth를 통해서 인증을 하고, 필요한 정보는 추가적으로 입력받는 형태로 많이 사이트가 변화했습니다

저희 서비스에서도 사용자들이 직접 ID, 패스워드를 만들기 귀찮아하는 문제를 해결하기 위해 Oauth를 도입하였습니다

OIDC(Open ID Connect)의 등장

위와 같이, 권한에 대한 부분을 신경 쓰지 않고, Oauth를 사용하게 되면, Oauth 흐름상 불필요한 요청이 가는 부분이 생기는데요

이를 해결하기 위해 2014 년에 새롭게 표준이 된 OIDC(OpenID Connect)가 나왔습니다

불필요한 요청을 제거하기 위해서 ID 토큰을 활용해 정보를 한 번에 넘기도록 방식을 변경했습니다

이 부분에 대해서는 아래에서 더 자세하게 설명드리도록 하겠습니다

Oauth 1.0a을 알아보자

지금은 사실상 사용되지 않는 과정이기에, 대충 넘어가도록 할 것인데요

출처 :  http://oauth.net/core/diagram.png

왼쪽이 전체적이 흐름, 오른쪽이 필요한 필드입니다

Oauth 1.0a 은 왜 사라졌을까?

1.0a 가 사라진 이유를 찾아봤을 때, 총 4가지가 메인 이유였습니다 

oauth_signature를 만드는 과정이 너무 복잡하다

오른쪽 필요한 필드에서 확인해 보면 사용자가 보내줘야 하는 필수 필드입니다

만드는 과정으로는 크게 4가지 과정이 있습니다 조금 더 자세하게 정리가 되어있는 곳입니다 

 

1. 요청 매개변수를 모두 모은다

Oauth_signature를 제외한 모든 Oauth_로 시작하는 매개변수나, body까지 모두 모읍니다

 

2. 매개변수를 정규화한다(인코딩한다)

사전순 정렬을 하고, 각각의 key, value를 URI encoding을 진행합니다

A=B&C=D 형태로 만들고, 전체를 URL 인코딩을 진행합니다

 

3, Signature Base String을 만든다

[GET|POST]&[매개변수제외 URL]&[정규화된 결과]

 

4. 키를 생성한다

HMAC SHA1 같은 암호화(or 해싱) 방식을 활용해 암호화를 진행한다

 

벌써부터, 필드를 직접 구현한다고 생각하면 코드가 지저분해지기 딱 좋은 부분이라는 생각이 듭니다

이 과정을 모든 클라이언트가 다 하는 것에 대한 부담이 있었습니다

클라이언트에 요구되는 높은 연산 속도

위 과정에 4번 키를 생성한다

이 과정에서 사용되는 암호화 알고리즘은 안전을 위해서, cpu 자원을 많이 사용하는 과정을 거칩니다

이 과정이 클라이언트에 들어가 있기에, 클라이언트가 부담을 가지게 됩니다

웹 환경에만 적절한 구조

2006년, 2008년은 이제 아이폰이 처음 나온 시기인데요

2007 년에 막 스마트폰이 처음 나왔기에, 스마트폰 같은 환경을 전혀 고려하지 않은 방식이었습니다

출처 : https://m.sedaily.com/NewsView/29LMBW1VEA

딱 한 가지 방식만으로 이루어진 Oauth 1.0a의 특징상 모든 클라이언트를 만족시킬 수 없었습니다

브라우저만으로 이루어진 사이트의 경우, 네트워크 탭을 통해서 충분히 확인할 수 있는 것을 여러 번을 거쳐서 소통하는 것처럼요

 

만료시킬 수 없는 토큰

처음 생각했을 때는 만료를 시킨다는 생각을 별로 하지 않았습니다

그래서 만료에 대한 부분을 다루지 않았는데요

실제 트위터에서는 2007년에 나온 Oauth1.0 토큰을 아직도 사용할 수 있습니다

 

위에 나온 4가지 단점을 극복한 새로운 웹 표준으로 Oauth 2.0 2012년 이 나오게 되었는데요

다음 글에서 Oauth 2.0과 OIDC(OpenID Connect)에 대하셔 자세하게 작성해 보도록 하겠습니다

 

요약

Oauth 1.0 은 너무 옛날에 나와서, 현재 사용하기 어렵다

Oauth2.0을 통해 사용자 인가를 하고

OIDC(OpenID Connect)를 통해서 사용자 인증을 할 수 있다

 

 

참고

https://hudi.blog/oauth-2.0/

https://d2.naver.com/helloworld/24942

https://blog.naver.com/mds_datasecurity/222182943542

https://www.oauth.com/