OAuth 2.0, Authorization Grant, Flux Architecture

블로그 첫 글

 

이번 주가 너무 바빠서 퀄리티 있는 글을 쓸 시간이 부족한 게 너무 안타깝다. 다음 주 부터는 세미나 끝나자마자 미리미리 조금씩 써놔야겠다. 여유 될 때 티스토리 커스텀 해서 블.꾸.도 열심히 해보려고 한다.. (블.꾸 추구미: 인파.. 아니 갓파)

 

오늘은 3개의 키워드에 관해 써보려고 한다.

- OAuth 2.0

- Authorization Grant

- Flux Architecture

 

저 3개의 키워드가 무슨 상관인가 싶을 수 있는데, 같이 묶어 쓰는 이유는 이번 세미나에서 다룬 내용이라 그렇다.

 

1. OAuth 2.0

OAuth 2.0(Open Authorization 2.0)란 인가를 위한 업계 표준 프로토콜이다. 인터넷 사용자들이 개인정보를 직접 제공하지 않고 기존 웹사이트 상의 본인의 개인정보를 타 웹사이트 혹은 어플리케이션이 가져갈 수 있도록 해주는 수단이다. 

2.0 버전은 1.0 버전에서의 보안 문제 등을 개선한 것이다.

즉 우리가 다양한 플랫폼을 처음 이용할 때 소셜 회원가입/로그인 하는 것을 생각해 보면 된다.

 

OAuth의 구성 요소는 다음과 같다.

• resource owner: 웹 서비스를 이용하려는 유저. 여기서 resource를 유저가 가진 개인정보라고 생각하면 쉽다.
• client: 애플리케이션 서버. client라는 것은 상대적인 표현인데 여기에서 서버를 이렇게 칭하는 이유는 OAuth를 이용하는 상황에서 resource(개인정보)를 요청하는 주체가 애플리케이션 서버이기 때문이다. 
• authorization server: resource를 얻을 권한을 부여해주는 서버이다. client는 여기로 authorization code를 주고 token을 발급받는다.
• resource server: 우리가 받아오려고 하는 resource를 보유하고 있는 타 애플리케이션 서버를 말한다. client는 여기로 token을 주고 resource를 받아올 수 있다.
• access token: resource owner가 자원에 대한 접근 권한을 인가했음을 나타내는 자격증명
• refresh token: access token보다 만료기간이 긴 토큰으로, access token이 만료될 때 refresh token을 이용해 재발급 받게 된다.

소셜 로그인을 할 경우, client가 resource owner로부터 동의를 얻고 resource server를 통해 client의 신원을 확인한다.

 

 

2. Authorization Grant

OAuth2 승인 방식의 종류는 다음과 같다.

• Authorization Code Grant Type: 클라이언트가 특정 리소스에 접근을 요청할 때 사용된다. 리소스에 접근하기 위한 사용자명, 비밀번호, authorization code를 활용해 리소스에 대한 access token을 받는다.
• Implicit Grant Type: authorization code를 교환하는 단계 없이 access token을 즉시 반환받아 인증에 이용한다.
• Resource Owner Password Credentials Grant Type: 클라이언트가 암호를 이용해 access token에 대한 사용자의 자격 증명을 교환한다.
• Client Credentials Grant Type: 클라이언트가 컨텍스트 외부에서 access token을 얻어 특정 리소스에 접근을 요청한다.

 

3. Flux Architecture

Flux Architecture는 2014년 페이스북에서 발표한 client-side 웹 애플리케이션을 만들기 위해 사용하는 디자인 패턴이다. 

Flux 패턴이 등장한 이유는 대규모 애플리케이션에서 데이터 흐름을 일관성 있게 관리함으로서 프로그램의 예측가능성(predictability)을 높이기 위함이다.

 

기존에는 보편적으로 MVC 패턴이 사용되었다. MVC는 Model, View, Controller를 의미한다. model에 데이터를 저장하고 controller로 해당 데이터를 관리(CRUD)한다. model의 데이터는 view로 전달되어 유저에게 보여지며, 유저가 view를 통해 데이터를 입력하면 model에 반영된다. model과 view는 서로를 업데이트 할 수 있으며 따라서 데이터 흐름은 양방향이 된다.

그런데 애플리케이션의 규모가 커진다면, model과 view 사이의 상호작용이 복잡해지게 된다. view가 여러 개의 model을 동시에 업데이트하고 model도 여러 개의 view를 업데이트하게 된다. 이러한 과정에서 한 model의 변화에 의해 view가 업데이트되면 그 업데이트된 view가 또다른 model을 업데이트할 수 있다. 이와 같이 복잡한 데이터 흐름으로 인해 의존성을 가진 model의 개수가 많아질수록, 각 model에서 발생한 이벤트가 퍼져나갈 때 그 결과를 예측하기 어려워진다. 

따라서 이러한 예측 불가능성의 문제를 해결하고자 양방향이 아닌 단방향 데이터 흐름을 이용하는 Flux 패턴이 등장했다.

 

Flux는 action,dispatcher, model, view 순서의 흐름을 통해 이해할 수 있다. 유저 입력을 기반으로 action이 생성되고 그 action은 dispatcher에 전달된다. 그에 따라 model의 데이터가 변경되면 view에 반영된다. 이러한 단방향의 데이터 흐름으로 애플리케이션을 만드는 아키텍쳐가 Flux이다.

 

action이란 데이터를 변경하는 행위로서 dispatcher에게 전달되는 객체이다. 

dispatcher는 모든 데이터 흐름을 관리하는 중앙 허브이다. dispatcher를 통해서만 store의 데이터를 조작할 수 있다. 

model(store)은 상태 저장소로서, 상태 그리고 상태 변경 메소드를 가지고 있다. 발생한 action의 타입에 따라 그에 맞는 데이터 변경을 할 수 있는 콜백 함수를 dispatcher에 등록한다. dispatcher에서 콜백 함수가 실행되고 상태가 변경되면 view에게 데이터가 변경되었음을 알려준다.

view는 리액트 컴포넌트로 생각하면 되는데 store에서 상태가 변경되었음을 전달받으면 최상위 view부터 자식 view까지 데이터를 내려보내게 된다. 새로운 데이터를 받은 view는 화면을 리렌더링하고, view에 유저가 조작을 가하면 그에 해당하는 action을 생성한다.

 

Flux의 각 구성 요소들은 단방향 데이터 흐름으로 연결되어 순서대로 역할을 수행하고, view에서 새로 데이터가 변경되면 처음부터 같은 순서로 실행한다. 

 

 

---

사진 출처

https://haruair.github.io/flux/docs/overview.html