OAuth 프로토콜

최근에 회사 내부 프로덕트에 기존 로그인 방식에서 구글 로그인 기능을 추가하자는 이야기가 나왔다.

아무래도 해외 유저를 위한 기능들을 추가했지만 그들의 로그인 유입이 낮은 것 같아 진입장벽을 낮추기 위해 

구글 로그인을 추가하기로 한 것이다. 전에 사이드 프로젝트를 만들면서 구글, 카카오 로그인을 도입한 경험은 있지만 오래전이기도 하고 

최근에 Flab에서 진행하는 개인 사이드 프로젝트에도 구글 로그인을 넣기로 해서 기왕 도입할때 공부까지 확실하게 해버리자! 하는 마음이 생겼다. 

OAuth 프로토콜... 개발 하면서 많이 들었지만 물어보면 음..그거..소셜 로그인? 이랬던 경험이 있어서 나 자신이 부끄러웠던 기억이 있다.

 

한번 블로그에 정리하면서 개념을 정리해보고자 한다! 게시글 맨 아래에 참고한 사이트들 링크를 넣어놨습니다!

 

1. OAuth 프로토콜 이론

open authorization

사용자들이 자신들의 비밀번호를 직접 주지 않고 자신들의 정보에 다른 웹사이트들이 접근할수 있도록 권한을 부여하는 수단.

접근 위임을 위한 개방형 표준

• 접근 위임 : 내 정보에 접근하는 권한을 다른 앱에게 위임하는 것.
• 개방형 표준 : 모든 사람들이 사용할 수 있도록 공개된 방식이며 사람들이 같은 방식으로 만들자고 정해놓은 약속

근데 왜 OAuth 프로토콜가 등장한 걸까?

OAuth 이전에 인증방식의 표준이 없었기 때문에 사용자는 기존 인증방식인 아이디 & 비밀번호를 사용함.

→ 보안상 취약한 구조

그래서 서비스들은 사용자들의 아이디 & 비번을 DB에 암호화해서 보관하는 등 다양한 형태의 보안 기술이 탄생함.

그리고 기본 인증이 아닐 경우 각 앱들은 각 회사가 개발한 인증 방식대로 사용자들을 확인함.

• 구글의 AuthSub
• AOL의 OpenAuth
• 야후의 BBAuth
• 아마존의 웹서비스 API 등등을 통해서 사용자 인증을 함.

⇒ 사용자의 아이디와 암호가 노출되지 않도록 하면서 API 접근 위임이 가능하도록

OAuth는 이런 제각각인 인증방식을 표준화한 인증방식임

 

2006년

• 트위터는 OpenID 탑재하는 작업 진행
• 소셜 북마크 사이트인 Ma.gnolia는, 회원이 OpenID를 사용하여 서비스에 접속할 수 있는 인증 방법을 필요로 하고 있었음.
• OpenID= 내가 누군지 증명(인증) 만 해주는 프로토콜하지만 OAuth와 목적이 다름.즉, OpenID를 사용한다는 것은 본질적으로 로그인하는 행동과 같음.
• OpenID의 주요 목적은 인증(Authentication)이지만, OAuth의 주요 목적은 허가(Authorization)
• 인증을 위한 표준 프로토콜, HTTP를 사용한다는 점에서 OAuth와 같음
• 로그인을 대신 해주는 시스템

⇒ 두 회사는 API 접근 위임에 대한 공개 표준이 아직 존재하지 않는다는 결론에 이름

API 접근 위임 : 내가 아니라 다른 앱이 대신 내 정보에 접근 할 수 있도록 API 사용 권한을 넘기는 것.

그렇게 2007년 OAuth 1.0 탄생

이후 보안 문제를 해결한 수정 버전인 OAuth 1.0 revision A 가 2008년에 나옴.

따라서 OpenID라는 방식으로 서비스가 제공하는 API를 사용하도록 하고 싶었는데

논의 해보니 엇? API 접근을 위임하는 표준이 아직 없네? 라고 생각한것.

=======================================================

 

2. OAuth 1.0과 2.0의 차이

OAuth 1.0의 대표 용어

• 사용자(user): 서비스 제공자와 소비자를 사용하는 계정을 가지고 있는 개인
• 소비자(consumer): Open API를 이용하여 개발된 OAuth를 사용하여 서비스 제공자에게 접근하는 웹사이트 또는 애플리케이션
• 서비스 제공자(service provider): OAuth를 통해 접근을 지원하는 웹 애플리케이션(Open API를 제공하는 서비스)
• 소비자 비밀번호(consumer secret) : 서비스 제공자에서 소비자가 자신임을 인증하기 위한 키
• 요청 토큰(request token) : 소비자가 사용자에게 접근권한을 인증받기 위해 필요한 정보가 담겨있으며 후에 인증이 완료 된 후에 접근 토큰으로 교환된다.
• 접근 토큰(access token) : 인증 후에 사용자가 서비스 제공자가 아닌 소비자를 통해서 보호된 자원에 접근하기 위한 키를 포함한 값

비유를 들어 OAuth 인증 과정 이해해보자!

마치 OAuth 인증은 타사에 방문하는 외부인이 특정 목적을 가지고 방문증을 발급 받아 목적을 수행할 수 있도록 해주는 것임. 따라서 외부인이 회사에서 정해진 곳에 가서 목적을 수행할 수 있도록 허가해주는것!

1. 나방문씨가 A 회사의 안내 데스크로 와서 A 회사의 김목적씨를 만나러 왔다고 함
   1. Consumer가 Request Token 을 요청하고 Service Provider 발급 한다.
   2. Request Token 발급 요청시 사용하는 매개변수

GET http://nid.naver.com/naver.oauth?mode=req_req_token&  
oauth_callback=http://example.com/OAuthRequestToken.do&  
oauth_consumer_key=WEhGuJZWUasHg&  
oauth_nonce=zSs4RFI7lakpADpSsv&  
oauth_signature=wz9+ZO5OLUnTors7HlyaKat1Mo0=&  
oauth_signature_method=HMAC-SHA1&  
oauth_timestamp=1330442419&  
oauth_version=1.0 HTTP/1.1

1. oauth_callback
   1. Service Provider가 인증을 완료한 후 리다이렉트할 Consumer의 웹 주소.
2. oauth_consumer_key
   1. Consumer를 구별하는 키 값
3. oauth_timestamp
   1. 요청을 생성한 시점의 타임스탬프.
4. oauth_nonce
   1. Consumer에서 임시로 생성한 임의의 문자열. oauth_timestamp의 값이 같은 요청에서는 유일한 값이어야 함. 이는 악의적인 목적으로 계속 요청을 보내는 것을 막기 위함.
5. oauth_signature
   1. OAuth 인증 정보를 암호화하고 인코딩한 서명 값
6. oauth_signature_method
   1. oauth_signature를 암호화하는 방법.
7. oauth_version
   1. OAuth 사용 버전

 

2. 안내 테스트에서 김목적씨에게 나방문씨가 방문했다고 연락한다.

1. 사용자 인증 페이지 호출 (Direct User to Service Provider)

Request Token 요청시 Customer는 Request Token으로 사용할 oauth_token과 oauth_token_secret을 전달 받음.

1. 그중 oauth_token을 사용해 Service Provider가 정해 놓은 사용자 인증 페이지를 User에게 보여 주도록 함.
2. 김목적씨가 안내 데스크로 찾아와 나방문시의 신원을 확인함.
   1. 사용자 로그인 완료
   Service Provider에서 User를 인증하는 과정

3. 김목적씨가 안내 데스크로 찾아와 나방문시의 신원을 확인함.

사용자 로그인 완료 -> Service Provider에서 User를 인증하는 과정

 

4. 김목적씨는 업무 목적과 인적사항을 안내 데스크에 기록함.

1. User 인증 과정이 완료된 후 Consumer가 oauth_callback에 지정한 URL로 리다이렉트함.
2. 그때 Service Provider는 새로운 oauth_token과 oauth_verifier를 Consumer에 전달
3. 이는 Access Token 요청시 사용됨.
   1. Request Token 발급을 요청할 때에는 Consumer Secret Key를 사용해 oauth_token_secret를 생성
   2. Access Token 발급을 요청할 때에는 Consumer Secret Key에 oauth_token_secret을 결합한 값(Consumer Secret Key + & + oauth_token_secret)을 사용해 oauth_token_secret를 생성. 암호화 키를 변경하여 보안을 더 강화

5. 안내 데스크에서 나방문 씨에게 방문증을 발급함 .

1. Access Token 발급
   1. oauth_token과 oauth_token_secret을 전달

6. 김목적씨 & 나방문씨는 정해진 장소로 이동해 업무를 진행

Access Token을 이용해 서비스 정보 요청

 

따라서 Access Token은 방문증이고 Access Token를 갖고있는 Consumer는 사전에 허락된 Service Provider의 오픈 API를 호출할 수 있는 것.

 

하지만 OAuth 1.0은

• 웹 어플리케이션이 아닌 어플리케이션에서는 사용자가 사용하기 곤란하다는 단점이 있음.
• 또한 절차가 복잡하여 OAuth 구현 라이브러리를 제작하기 어려움.
• HMAC을 통한 암호화를 하는 번거로움
• 인증 토큰이 만료가 되지 않아 토큰을 만료하려면 어플리케이션의 비밀번호를 바꿔야 하는 단점.

⇒ 서명, 키관리, 복잡함.. 이런 단점을 개선하기 위해 OAuth 2.0이 생김

 

OAuth 2.0의 특징

1. 주로 서버 사이드 웹 애플리케이션 대상이 아니라 모바일 및 다양한 클라이언트에서 사용할 수 있게끔 지원
2. 복잡한 암호화가 필요 없고 HTTPS 통해 암호화하여 과정을 단순화 했음.
3. Siganature 단순화 정렬과 URL 인코딩이 필요 없음
4. API 서버에서 인증 서버와 리소스 서버가 분리됐다.
5. OAuth 1.0에서 Access Token을 받으면 Access Token을 계속 사용할수 있었음.
   1. 하지만 보안 강화를 위해 만료 시간을 지정함.
      • 왜 Access token의 만료시간이 없으면 보안이 안좋을까?
        • 유출자가 평생 그사람인척 하면서 내 데이터를 빼갈수있음.
        • 만약 access token이 유출되었다면? 유출자가 평생 그사람인척 하면서 내 데이터를 빼갈수있음.
   2. Refresh Token 추가

OAuth 2.0의 구성

• Resource owner : 리소스 소유자 및 사용자
  • 보호된 자원에 접근할 수 있는 자격을 부여해주는 주체
  • 인증이 완료되면 권한 획득 자격 (Authorization Grant) 을 client에게 부여함.
  • 권한 서버가 리소스 소유자와 클라이언트 사이에서 중개 역할을 수행함.
• Client : Resourse server에서 제공하는 자원을 사용하는 앱
  • 보호된 자원을 사용하려고 접근 요청을 하는 앱
• Resourse server(API server) : 사용자의 보호된 자원을 호스팅하는 서버
• Authorization Server(권한 서버): 사용자의 동의를 받아서 권한을 부여하는 서버
  • 인증/ 인가를 수행하는 서버, 클라이언트의 접근 자격을 확인, Access token 발급해 권한을 부여하는 역할 수행 
• OAuth 2.0 인증 프로세스
  • 

1. Authentication
   1. 인증, 접근 자격이 있는지 검증하는 단계
2. Authorization
   1. 인가, 자원에 접근할 권한을 부여하는 것.
   2. 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여됨.
3. Access Token
   1. 리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되고
   2. 만료 기간이 있는 token
4. Refresh Token
   1. Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token
   2. Refresh Token은 일반적으로 Access Token보다 만료 기간이 김.

 

Refernce

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

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

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