[OAuth 2.0] OAuth 2.0에 대해 알아보자!

프로젝트 진행중에 소셜로그인 구현이 필요해서 이 기술에 대해 처음 접하게 되었다.

그냥 무턱대고 사용하기보다, 얘가 무엇이고 왜 필요한지에 대해 공부해보고 사용해보고 싶었다.

 

OAuth 2.0은 무엇인가?

일단, 얘가 무엇인지 알아야 한다.

OAuth 2.0의 공식문서 첫 문단에 소개가 나와있다.

OAuth 2.0 is the industry-standard protocol for authorization.
OAuth 2.0 focuses on client developer simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices.

정리하자면,

Authorization(인증)을 위한 표준 프로토콜이며,

web, 모바일 및 기타 등등에서 특정한 authorizatioin(인증)을 제공할 때, client 개발자의 편의섬에 초점을 맞추고 있다.

 

그렇다면, 얘가 왜 필요할까?

OAuth 등장 배경

내 이름을 딴 Bada라는 사이트를 만든다고 가정해보자.

Bada는 사용자의 구글 계정의 연락처 목록에 접근하고 싶었다.

이를 위해서, Bada가 사용자의 허락을 받아 사용자의 구글 id, pw를 수집하여 접근할 수 있다.

하지만 이런 방법이 옳을까? 절대 아니다!

 

문제점은 크게 두 개이다.

1) Bada는 연락처 목록 뿐 아니라, 구글 내의 사용자의 모~든 정보에 접근이 가능하다.

2) Bada는 사용자에게서 받은 구글 pw를 평문으로 사용할 수 있는 방식으로 저장해야 한다.

→ 말할 필요도 없이 보안에 매우 취약하다.

 

그래서, 사용자의 구글 pw를 공유하지 않고도, 구글의 연락처 목록 정보에 대해 접근 권한을 부여할 수 있는 Authorization Framework가 필요했다. 

 

이 것이 OAuth의 등장 배경이다.

OAuth 2.0 흐름

Client Application    : Bada

Authorization Server : 구글(인증)

Resource Server       : 구글(정보 제공)

Resource Owner      : 사용자

 

1. Client Application들은, Authorization Server에 Access Token을 요청할 수 있다.

2. Resource Owner들은 Authorization Server에 로그인하고, Client Application이 특정 정보에 접근할 수 있도록 동의하면 된다.

3. 발급받은 Access Token이 있으면, Client Application은 Resource Server에 사용자에 대한 특정 정보를 요청해 받을 수 있다.

 

위 흐름을 통해서,

1) 우리가 위에서 하고자했던 Bada가 사용자의 구글계정의 연락처 목록을 받아올 수 있다.

2) Bada는 사용자의 구글 pw를 알 수 없으며, 접근을 동의한 정보 이외의 다른 정보에 접근할 수도 없다. (문제점 해결)

 

OAuth 2.0 구현

크게 세 가지 방식으로 구현할 수 있다.

참고자료 → 공식문서에 링크되어있는 참고자료이며, 직접 꼭 읽어보기를 바란다. 이해가 아주 잘됨!

1. implicit flow (암시적 흐름)

implicit flow

SPA(Single Page Application)에서 implicit flow로 구현된 OAuth2.0를 사용했을 때 문제가 발생한다.

위 그림에서 6. Respond with TOKENS 과정이 이루어질 때, 브라우저의 url에 token이 노출되기 때문이다.

 

TOKEN을 줄 때, Client App의 callback url을 호출하여 전달하는데,

이 때 전달되는 Token이 Query 파라미터 형태로 전달되기 때문이다. 

 

그래서, 이런 일을 막기위해 OpenId Connect(OIDC)가 등장한다.

OIDC is a thin layer on top of OAuth 2.0 that introduces a new type of token: the Identity Token.

뒤의 2,3번에서 code라고 불리는 identity를 위한 token을 추가로 사용하는 방식이다.

 

2,3번 모두 OAuth2.0 + OIDC 를 이용한 방식이며, 어떤 flow를 사용했냐가 다르다.

2. Authorization Code Flow 

위의 implicit flow와의 가장 큰 차이점은,

callback url로 바로 token을 전달받는 것이 아니라, code를 전달받는 것이다.

Client App은 이 code로 Authorization Sever에 Token을 요청한다.

(Token을 response body형태로 받을 수 있어 노출되지 않는 것이다.)

 

Client Secret이 신원확인(Credentials)을 위한 용도로 사용된다.

 

* Client ID vs Client Secret

Client ID가 이미 있는데 왜 Client Secret이 추가로 필요한지가 의문이 들었다.

OAuth의 관련문서를 읽어보면, 잘 설명되어있다.

요약하자면,

Client ID는 public하다. (Application을 위한 공개 식별자이다.)

Client Secret는 말 그대로 비밀. private하게 숨겨져야 하는 값이다. (Client App과 Authorization Server만 알고있도록)

 

github의 OAuth를 이용할 때, 로그인 페이지로 redirect시키는데, client_id가 노출되는 것을 볼 수 있다.

3. PKCE (Proof Key for Code Exchange)

2번의 Authorization Code Flow와의 가장 큰 차이점은, Client Secret이 없다는 것이다.

Client Secret의 단점은, Authorization Server에서 미리 발급해주는 고정 암호라는 것이다.

Client App에서 이 값을 어디엔가 저장해놔야하기 때문에 유출될 가능성이 있다는 것이다.

그래서! 

동적으로 생성하는 일회용 암호를 만들어 Client Secret 대신에 이용한다. 

위 흐름도에서 노란색 형광펜으로 칠해진 부분이 관련 내용이다.

 

이 공부를 하면서, github의 OAuth App을 만들어 테스트해보았는데 github에서는 2번 방식인 Client Secret을 이용하고 있었다.

 

 

후기

인증 프로토콜을 공식문서로 공부해 본 것은 처음이었다.

작년에 블로그 몇 개를 봤었는데 쉽게 이해가 되지 않았었다. 이번에는 공식문서로 공부했기 때문에 이해가 더 잘되고 깊은 부분까지 볼 수 있었던 것 같다.

 

소셜로그인 구현이 필요해서 접하게된 프로토콜이었는데, 그냥 가져다쓰지 않고 이렇게 이해하고 사용하게 되어서 좋다!

 

 

 

 

 

정확하지 않은 정보가 있을 때 댓글로 알려주시면 감사드리겠습니다 :)