-
Notifications
You must be signed in to change notification settings - Fork 3
기술공유 01. Passport와 Apollo를 활용한 oAuth 인증 시스템
Jaewon Kim edited this page Nov 25, 2019
·
2 revisions
-
장점(Pros)
- 세션쿠키에 httpOnly 옵션을 줌으로써 XSS 공격에 대비할 수 있다.
- https 프로토콜을 사용하지 않는 경우에 secure 옵션을 통해 암호화를 해서 네트워크 레이어에서 탈취되는 경우에 대비할 수 있다.
- SameSite 옵션을 통해 크로스도메인에서 발생하는 쿠키는 무시할 수 있다.
- 즉 1~3번의 이유로 보안을 강화시킬 수 있다.
-
단점(Cons)
- 확장된 어플리케이션에서 관리가 용이하지 않다. (특히 micro service architecture) 이 경우에 중앙화된 세션관리 서버가 필요한데, 세션관리 서버가 다운될 시 전체 시스템에 영향을 줄 수도 있고, 서버간 의존이 생기기 때문에 시스템 복잡도가 올라간다.
- DB / 서버의 구현로직이 추가되기 때문에, 구현의 복잡도가 높아진다.
-
장점(Pros)
- 서버에서 별도의 데이터관리가 필요하지 않고, request Header 를 통해 토큰만 전달해주면 되기 때문에, http의 비연결성 특징과 잘 맞아 구현이 간단해진다.
- 여러 서버로 서비스가 분리되어 있을 때, 서로의 서비스에 영향을 덜 줄 수 있다.
-
단점(Cons)
- 세션을 지속적으로 유지시키기 위해서, localStorage 등을 사용할 경우 토큰이 탈취될 위험(CSRF 공격)이 존재한다.
- 위와 같은 이유로 XSS 공격에도 취약할 수 있다.
- 즉, 보안이 취약해진다.
-
보안 개선점
- AccessToken, RefreshToken 전략을 통해서 미흡한 보안을 어느정도 보완할 수 있다.
-
선택한 이유
- Dropy는 누구나 쉽게 접근하고 공유하는 서비스로 사용자에 대한 민감한 정보를 다루지 않는다. (사용자 이름 정도만 활용한다.)
- 토큰을 탈취해도 메리트가 없다. (채널 만드는 권한정도)
- 서버를 용도에 맞게 나누어 개발했다. (Api, Web, Converter, Image) 따라서 토큰인증 방식이 구현이 편리하다.
- 클라이언트 측에서 Service Provider 에게 AccessToken 을 발급받고 받은 토큰을 바로 서버에 전달한다.
- 서버는 클라이언트에게 전달받은 AccessToken 을 이용해서 Service Provider 에게 사용자 정보를 받는다.
- 사용자 정보를 DB에 저장 후 자체 Token 을 발급해서 클라이언트에게 전달한다.
- 클라이언트는 토큰을 Cache 와 Local Storage 에 저장한다.
- 앱 처음 실행 시 로컬 스토리지에서 토큰을 확인해서 캐시에 저장한다.
-
Apollo-Link
기능을 이용해 응용소프트웨어 단계에서 클라이언트 측 네트워크 Layer 를 나눈다. -
AuthLink
를 통해 헤더값에 캐시의 토큰을 읽어 적재한다. -
HttpLink
를 이용해서 http 프로토콜로 요청이 전송된다. -
Apollo Server
는 토큰을 사용자 정보로 변환해서 resolver 에 Context 값으로 넣어준다.
© BoostCamp 김김이조.
Members
'김'도현 (happydhKim) | '김'재원 (load0ne) | '이'미림 (always-awake) | '조'애리 (aereeeee)
-
Plans
-
Rules
-
Style Guides
-
Sprint Meeting Logs