간편로그인 & 상태관리

간편로그인

---

멋사 해커톤 때, 간편로그인은 네이버만 구현에 성공했고 구글 로그인 api는 연결하다가 DB가 꼬이는 사고가 생겼었다. 

이번 기회에 제대로 공부해 보도록 하자!

 

OAuth 2.0

 

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.

 

편리성과 보안이라는 2가지 장점을 갖고 있기에 많이 사용된다!

1. 편리성

OAuth 2.0은 사용자가 여러 웹사이트나 애플리케이션에서 동일한 계정으로 로그인을 가능하게 해줍니다.

Google, Facebook, GitHub 등의 계정을 사용하여 별도의 회원가입 없이 다양한 서비스에 접근할 수 있습니다.

이로 인해 사용자는 여러 개의 아이디와 비밀번호를 기억할 필요가 없으며, 로그인 절차가 간소화됩니다.

2. 보안

OAuth 2.0은 사용자 비밀번호를 직접 전달하지 않습니다.

그렇기 때문에 사용자 자격 정보가 노출될 위험을 줄여주며, 민감한 정보가 타사 애플리케이션과 공유되지 않으므로 안전합니다.

또한, 토큰 기반 인증으로 특정 권한을 부여할 수 있어 권한을 제한하고 필요에 따라 사용자가 쉽게 철회할 수 있습니다.

 

간편로그인에는 3가지 구성 요소들이 존재한다.

1. Resource Owner
2. Client 
3. Authorization Server

Resource Owner: 유저,

Client: 내가 만든 서버

Authorization Server: 소셜로그인 제공처(네이버, 카카오, 구글...)

이라고 할 수 있다. 

 

 

그리고 크게 3단계로 나뉜다.

1. 인가 코드 받기
2. 토큰 받기
3. 사용자 로그인 처리

 

1. 인가 코드 받기

 

여기서는 크게 2가지 기능을 수행한다.

1. 프론트엔드 화면을 카카오 로그인 화면으로 리다이렉트시키기
2. 사용자가 해당 화면에서 카카오 계정 정보를 입력하면, Redirect URI에서 인가 코드를 받아오기

인가 코드란 카카오네 집에 가는 '초대장'이다.

네이버 로그인을 구현할 때 Redirect URI가 대체 뭔지 궁금했는데, 카카오가 내게 초대장을 보내는 '주소'라고 생각하면 된다. 

유저가 올바른 아이디와 비밀번호를 입력하면 카카오는 Redirect URI로 인가 코드를 전송해 준다. 

 

 

2. 토큰 받기

 

인가 코드가 초대장이지만, 초대장을 받는다고 다가 아니다!

카카오에서 제공하는 유저들의 정보에 접근하려면 초대장뿐 아니라 '열쇠'도 가지고 있어야 한다. 

 

그 열쇠는 곧 '토큰'이다. 

전 단계에서 카카오가 준 인가 코드를 다시 카카오로 보내면,

카카오는 유저가 누구인지, 제대로 로그인했는지 검사하고,

이상이 없다면 토큰(유저 정보에 접근할 수 있는 열쇠)을 넘겨준다. 

 

 

3. 사용자 로그인 처리

 

이제 카카오로부터 사용자의 정보를 받아올 준비가 끝났다.

토큰(열쇠)을 카카오 측에 넘겨주면,

카카오는 그것을 확인한 뒤 id, 프로필 사진 등의 유저 정보를 넘겨줄 것이다.

어떤 정보를 받을지는 직접 설정할 수 있다.

 

 

 

 

Authorization Grant

---

 

 

Authorization Grant란 OAuth의 권한 부여 방식이다. 

구체적으로 말하면 Client가 Resource Owner의 허락을 받아 액세스 토큰을 얻는 과정이다.

Authorization Grant에는 총 4가지 주요 타입이 있다. 

1. Authorization Code 

- 구글, 페이스북, 카카오톡이 채택하는 간편 로그인 방식이다.

 

-사용자의 비밀번호 같은 민감한 정보가 클라이언트와 공유되지 않아 보안이 강화된다.

2. Implicit 

이 방식은 Authorization Code 방식과 비슷하지만, 주로 단일 페이지 웹 애플리케이션(SPA) 같은 경우에 사용된다.

여기서는 인가 코드를 따로 받지 않고, 클라이언트가 바로 액세스 토큰을 받는다. 즉, 중간 단계 없이 리소스 소유자가 클라이언트에게 곧바로 접근 권한을 주는 것이다.

Implicit 방식은 사용이 간편하지만, 보안 측면에서는 상대적으로 취약하다.

그래서 최근에는 PKCE(Proof Key for Code Exchange)를 적용한 Authorization Code 방식을 더 권장하고 있다고 한다.

3. Resource Owner Password Credentials 

이 방식은 사용자가 직접 클라이언트에게 자신의 아이디와 비밀번호를 제공하여, 클라이언트가 이를 이용해 액세스 토큰을 얻는 방식이다. 이 경우, 클라이언트와 자원 소유자 간에 높은 신뢰가 전제되어야 한다.

이 방식은 보안상 리스크가 클 수 있기 때문에, 가능한 다른 인증 방식을 사용하는 것이 좋다. 다만, 신뢰할 수 있는 환경에서는 이 방식이 간편하게 사용될 수 있다.

4. Client Credentials 

이 방식은 OAuth2에서 가장 간단한 권한 부여 방식이다. 주로 시스템 간의 인증에 사용되며, 특정 사용자 대신 클라이언트 자체가 리소스에 접근할 때 사용된다. 예를 들어, 특정 유저의 데이터가 아닌 시스템 자체의 데이터를 다룰 때 사용된다.

이 방식은 사용자 정보와 무관한 경우에 적합하며, 클라이언트가 자신이 소유한 리소스에 접근하는 데 주로 사용된다. 보안 위험이 낮고, 복잡하지 않은 경우에 사용하기 좋다.

 

 

 

Flux Architecture

---

 

Flux는 주로 React와 함께 사용되는 아키텍처 패턴이다. 단방향 데이터 흐름을 강조하는 구조로, 데이터가 한 방향으로만 흐른다는 게 큰 특징이다. Flux에서의 주요 구성 요소는 다음과 같다.

• Action: 사용자의 입력/애플리케이션 내의 이벤트 표현
  • 예) 버튼 클릭/API 요청 
• Dispatcher: Action을 받아서 처리 결정 & Store에 전달
• Store: 데이터를 저장하는 곳. 애플리케이션 상태(state)를 관리 & Dispatcher로부터 Action을 받아서 상태 업데이트
• View (Component): Store로부터 데이터를 받아 화면에 렌더링(React의 컴포넌트)

Flux 데이터 플로우

Flux에서는 단방향 데이터 흐름이 발생한다. 그 역은 존재하지 않는다!

Flux의 장점

• 예측 가능성: 데이터가 항상 한 방향으로 흐르기 때문에, 애플리케이션의 상태 변화를 추적하기가 쉽다.
• 상태 관리 용이: 대규모 애플리케이션에서 상태가 복잡하게 얽힐 때, Flux는 상태 변화를 체계적으로 관리할 수 있다.

 

3. MVP와 Flux의 차이

데이터 흐름

• MVP: 양방향 데이터 흐름을 지원한다. View와 Model 간의 상호작용이 Presenter를 통해 이루어지며, 사용자의 동작에 따라 데이터를 주고받는다.
• Flux: 단방향 데이터 흐름만 나타난다. 사용자가 액션을 발생시키면 데이터는 오직 한 방향으로만 흐른다.

구성 요소 간의 역할

• MVP: Presenter가 모든 중재 역할을 담당. 사용자의 입력과 비즈니스 로직은 Presenter가 관리하며, View는 Model에 직접 접근하지 않는다.
• Flux: Store와 Dispatcher를 통해 데이터를 관리하고, View는 그 결과를 화면에 반영한다. Store는 데이터를 단독으로 관리하며, View는 데이터 변화를 반영할 뿐이다!

---

4. 어떤 상황에서 어떤 구조를 사용할까?

• MVP: 뷰와 비즈니스 로직을 철저히 분리하고, Presenter를 통해 데이터를 중재하는 것이 적합한 경우에 사용하면 좋다. 특히 테스트가 중요하거나 중간자 역할이 필요한 상황에서 유리하다.
• Flux: 복잡한 상태 관리가 요구되는 대규모 애플리케이션에서 매우 효과적이다. React와 함께 사용할 때 단방향 데이터 흐름이 애플리케이션의 상태를 쉽게 관리할 수 있게 해준다.