OAuth2.0 이란?

목적

ID / PW 로그인 방식이 아닌 '카카오로 로그인하기' , '네이버로 로그인하기' 와 같은 타 시스템으로 로그인하는 기능 적용에 사용되는 OAuth가 무엇인지 또한 동작 원리를 정리해보려함. 

wadiz.kr의 로그인 화면

우선 인증이 뭐지...? 또 인가는 뭐란 말인가...

인증(Authentication) vs 인가(Authorization)

- 인증 (Authentication) : 유저가 누구인지, '접근을 허가함'을 의미.

- 인가 (Authorization) : 유저에게 권한을 줄지, '행위에 대한 권리를 검사함'을 의미.

 

예를 들어 어느 회사에 최종 합격을 했다고 하자. 아이디는 입사 전에 이미 타부서에서 만들어 주었을 것이다. (인증)

아이디는 있지만 아무것도 할수 없다. ( ex. 서버 접근, DB 접근 등..) 그래서 우리는 결재를 올려 권한을 요청한다.

타부서에서는 해당 아이디에 특정 권한을 부여한다. (인가)

OAuth

비밀번호 사용에 따른 로그인 방식은 보편적으로 ID/PW를 DB에서 확인하여 쿠키 또는 세션 값에 인증 처리되어 로그인 권한이 부여가 된다. 하지만 다른 어플을 사용했을때 , 해당 어플에 따른 아이디를 다시 가입을 해야한다.

만약 그 어플의 아이디를 까먹었다면?

핸드폰 인증 받고.. 인증 번호 입력하고 .. 주민번호 인증에 앱껐다가 켰다가.. 이러한 경우처럼 서로 다른 서비스 간의 정보를 얻기 어렵다.

또한 그때 그때 권한에 따른 사항을 DB에 요청을 하는 case가 발생한다면 resource 낭비도 심할 것이다. 가장 안좋은건 , PW가 하나로 관리되어지기 때문에 신뢰성/유연성  등 모든것이 PW 유무에 달려있다. 

 

그래서 나온 기술이 OAuth 1.0 이다.

 

OAuth 1.0 vs OAuth 2.0

OAuth라 함은 보통 OAuth2.0을 말한다. (현재 2.1까지 나온것 같다.) 이 둘의 차이는 다음과 같다.

 

1. Service Provider -> Resource Server , Authorization Server 분리

  아래에서 설명하겠지만 Resource Server와 Authorization Server라는 것이 있다. 1.0에서는 두 서버가 하나로 되어있어 인가(Authorizaiton) 과 resouvce 제공하는 웹서비스에서 동기화 관련 보안 이슈를 해결하였다.

 

2. API 호출시 인증 방식 변경 (서명->Https)

 

3. 클라이언트 지원 유형 변경 (웹 -> 웹/앱..)
  다양한 유형의 클라이언트를 고려하여 클라이언트별 기능을 공통으로 구현

 

OAuth2.0 동작방식

우선 참고한 블로그 및 RFC문서이다.
https://showerbugs.github.io/2017-11-16/OAuth-%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%BC%EA%B9%8C

https://datatracker.ietf.org/doc/html/rfc6749

RFC 6749 - The OAuth 2.0 Authorization Framework

OAuth 란 무엇일까 · Showerbugs

 

OAuth2.0 의 동작방식을 이해하기 전에 주체 관계를 이해하기 위해, 주체가 무엇이 있는지 정리해보았다.

 

1. Resource Owner : 사용자 ( 앱을 사용하는 )

2. Client : Resource Server에서 제공하는 자원을 사용하는 어플리케이션 (ex. 위 로그인 화면처럼 와디즈? 또는 여타 '카카오로 로그인하기' , '네이버로 로그인하기'를 사용하는 어플리케이션)

3. Resource Server : 자원을 제공하는 서버

4. Authorization Server : 사용자의 권한을 제공하는 서버

( 3번과 4번은 Naver나 카카오, 구글처럼 로그인을 제공하는 군에 속한다.)

 

 

주체에 따른 동작 방식을 글로 이해하니 힘들었다.......

 

시퀀스다이어그램을 하나 만들어보았다.

OAuth2.0 시퀀스

 

우리는 와디즈에서 카카오 로그인을 하려는게 목표다!!

<순서>

1 : 사용자는 클라이언트에게 로그인을 요청한다. ( 와디즈 화면 )

2 : 클라이언트는 인가서버에게 로그인 화면을 보여달라고 요청한다. ( 카카오 로그인 화면으로 넘어간다. )

3 : 사용자는 기존에 자신이 가지고 있는 로그인 정보를 입력한다. ( 카카오 계정을 입력한다.  )

4 : 인가서버는 사용자 로그인이 확인되면 Access Code를 발급 

5 : Callback URL Redirect

6 : AccessToken 요청 및 클라이언트에게 Token 발급

-----------------------------인증완료----------------------------------

7 : 인증이 완료된 사용자이므로 API 를 통해 resource 서버로 요청 및 응답 받는다. 

(ex. id, email, 나이 그외 카카오/네이버/구글 등에서 이용할 수 있는 서비스 제공받는다. )

 

종류

인증의 종류는 4가지가 있다. 위에서 언급한 RFC 문서 1.3.1 ~ 1.3.4 에 관련 내용이 존재한다. 위 순서에서 4번에 대해 4가지 다른 방식이 있는데 아래와 같다.

 

1. Authorization Code  : 위에서 설명한 내용. 권한에 따른 AccessCode를 발급해준다. 클라이언트가 사용자 대신 Resource 접근시에 사용한다. 대부분의 소셜 미디어 어플리케이션에서 사용.

2. Implict : 권한 부여 코드(Access Code) 없이 사용자 자격 증명한다. (특정 상황이 아니라면 크게 추천하지 않는 방식)

3. Resource Owner Password Credential : 리소스 소유자 ( Resource Owner , 사용자 )가 직접 암호 자격을 증명해서 승인하는 방식. 

4. Client Cridentials : 이번엔 리소스 소유자가 아닌 클라이언트가 직접 자격 증명하는 타입