[Study] 인증/인가(회원가입, 로그인)

[Akgop]

@ttttoooommm @hydenny @oss5824 @Akgop @kimmincheol-kor @jyh4479 @YuHyeonGeun-KOR

댓글에 자료 조사해서 공부한거 공유해보면 좋을듯 합니다

인증 / 인가

우리 서비스의 인증/인가 방식을 어떻게 구현할 지 공부해보고 정합시다. 로그인, 회원가입을 구현하는 방법에는 여러가지가 있습니다. 간단하게 쿠키, 세션, 토큰을 이용하는 방식이 있는데, 이번 프로젝트에서는 토큰 방식을 사용해봤으면 좋겠습니다.

공부 키워드

• Cookie
• Session
• JWT(JSON Web Token)
• Oauth
• 추가로 인증/인가에 필요한 다른 지식들 대환영

[Akgop]

인증, 인가란?

• 인증(Authentication): 말그대로 인증이다. 이 사람이 출입할 수 있는지. 즉, 우리 서버에 접속해도 되는지 검사하는 것.
• 인가(Authorization): 이 사람이 여기에 접속할 수 있는 권한. 예를 들어, 무료 사용자가 유료 사용자의 권한에 접근하면 안된다. 이런 접근 권한을 관리하는 것이 인가이다.

  웹 서비스에서 인증, 인가 방법?

  HTTP BASIC

• 매우 기본적인 방법이다. 사용자는 401응답이 왔을 경우 {id, password}를 Authorization 헤더 필드에 포함해서 보낸다. 이 때 base64 방법을 통해 인코딩 한다. base64는 암호화가 아니기 때문에 도청되면 id, pwd가 노출된다. 따라서 위험.

  쿠키(Cookie)

• HTTP는 stateless 프로토콜이다. 따라서 사용자가 로그인을 했었는지, 저장을 못한다.
• 따라서 Cookie 도입. Cookie를 이용하여 사용자를 식별할 수 있는 정보를 Set-Cookie 헤더에 주입하여 요청이 들어왔을 때, 쿠키를 판별하여 인증
• 그러나 쿠키도 XSS(Cross Site Scripting)공격등을 통해 탈취가 가능하다. HttpOnly 옵션을 넣어 브라우저(Javascript)를 통해 쿠키를 확인하지 못하게 만들면 안전해진다. 네트워크 패킷을 직접 감청하는 것은 해결이 안된다.
• BASIC 보다는 안전하지만 여전히 위험하다.

  세션(Session)

• 세션은 Set-Cookie에 세션 ID를 저장.
• 쿠키와 다른점은, 쿠키는 쿠키를 client에 저장하고, 세션은 server에 저장한다는 점이다.
• 즉, 세션 디비를 통해 서버에서 관리를 해줘야 한다는 것. 따라서 중간에 패킷이 직접 탈취되지 않는이상 문제가 없다.
• 그러나 중간에 탈취가 되어도 서버측에서 expire, TTL등으로 해당 세션을 만료시키면 더이상 인증되지 않는다.
• 따라서 쿠키가 털릴 것을 대비해서 expire를 짧게 주면 된다. 또한, 쿠키에 사용자 정보가 직접 안들어가서 안전하다.
• 하지만 HTTP는 기본적으로 stateless인데 사용자 정보를 저장하는 stateful 한 상태가 되버림. 또한 expire가 만료되기 전에 액세스 된다면 결국 털리는건 똑같다.
• 서버가 규모가 커지며, 분산을 통한 scale-out을 해야 하는데, 모든 서버에 모든 사용자의 세션ID가 들어간다면 중복된다. 따라서 이런 경우 인증을 위한 세션 서버를 아예 따로 두게 된다.
• 근데 세션을 따로 두게 되면 서버 부하가 생기고, CORS에서 사용이 어렵다고 하는데 여기좀 알려주셈

  토큰: JWT(JSON Web Token)

  1. Secure Server에 로그인 → 인증되면 JWT를 클라이언트에게 반환
  2. 클라이언트는 해당 토큰을 바탕으로 여러 microservice에 토큰을 가지고 접속
  3. 서버는 토큰을 시크릿 키로 해독하여 유효한지 검사하고, 만료되었는지 검사한다.
• 토큰 내부에는 중요한 정보를 담지 않는다. 하지만, 토큰을 해석하는 시크릿 키는 절대로 탈취당하면 안되기에 서버측에서 관리를 잘 해야할 것을 요한다.

  결론

• 지금 우리 서비스는 소규모지만 토큰 방식을 연습해보는게 제일 좋을 것 같음.
• 세션방식, 토큰방식에 대해서 내가 부족하게 알고 있는점 이나 오류 있으면 피드백 해주십쇼

[jyh4479]

최근 많은 기업들이 서버구조를 MSA(Micro Service Architecture)로 구축하는경우가 대부분 실제로 내가 네이버에서 인턴할때도 기존에 Monolithic한 Legacy를 MSA구조로 재구축하기전에 프로토타입을 만드는 내용이었고 KOLON에서도 실제로 전환작업을 하고있는 팀이있음 관련 내용은 면접에서도 많이 질문하는 내용이니까 한번 훝어보고 넘어가세요

MSA같은 경우는 서버를 여러개로 분산시켜놓기때문에 세션 방식을 사용하면 각 서버가 세션을 가지고있고 관리해야하는 문제가 있기때문에 JWT와 OAuth2.0이 주목을 받게 되었다고 알고있음 OAuth와 관련된 내용은 아직 잘몰라서 각자 잘 찾아보고 의견을 나눠봤으면 좋겠습니다

[Akgop]

@ttttoooommm @hydenny @oss5824 @kimmincheol-kor @jyh4479 @YuHyeonGeun-KOR 추가로 공부한 내용 정리하겠슴다. 아래 쪽에 우리 프로젝트에서 로그인, 회원가입, 로그아웃을 어떻게 구현할 지 제안하는 부분이 있으니까 꼭 읽어주고 피드백 해주십쇼~~!

JWT (JSON Web Token)

JWT 를 사용하면 발생하는 문제점중, 가장 큰 것은 토큰이 탈취 당한다는 것. 토큰이 탈취 당하면 탈취한 해커는 이를 이용해서 서버에 여러 공격을 수행할 수 있다. 따라서 이를 방지하기 위해 여러 방법이 도입되었다.

토큰 Expires Time을 엄청 짧게 한다.

토큰이 탈취 되어도 금새 만료 되어서 무효한 상태로 만들어 버린다.

• 그러면 사용자가 매번 로그인을 해야 하는가? 너무 불편하다. 따라서 사용자가 로그인을 할 시 토큰 2개를 발급한다. 이를 각각 access, refresh로 구분한다. access token의 만료 기간은 매우 짧게 한다. refresh는 좀 더 길게 설정한다. 그리고 access token을 자주 만료 시키고 만료 되었다면 (419 status code) refresh token과 만료된 access token을 통해 새로운 access token을 생성한다.
• refresh token은 뭔가요?? refresh token은 서버가 저장하고 있으면서 만료된 access token을 재발급 하기 위한 용도이다.
• 서버 어디에 저장하나요?? DB 접근 하려면 복잡할 것 같은데.. 그래서 MSA 아키텍쳐의 경우 인증 서버를 하나 둔다. Secure Server를 두고, Redis 에 Refresh Token을 저장하여 빠르게 액세스 할 수 있도록 한다. MSA 아키텍쳐에 대해서는 나도 아는게 많이 부족하므로 아래 참조 링크를 걸어두었음..
• refresh token이 탈취 당하면?? 이럴 확률은 상대적으로 낮다. 왜냐하면 refresh token이 네트워크 상에서 패킷으로 유통되는 순간은, 로그인 한 순간(발급될 때), access token의 재 발급을 요청할 때 밖에 없기 때문이다. 따라서 네트워크 통신 시에 탈취될 확률은 꽤 적다고 본다.(아닐 수 있음)
• DOM 조작으로 탈취 해버리면?? token들을 cookie에 넣기 때문에, 해커가 getDocumentById.cookie 등으로 가져갈 수가 있다. 하지만 cookie의 옵션을 httpOnly를 걸어버리면 DOM 조작이 불가능 해져서 안전해진다.
• 그래도 탈취 당하고 아직 만료가 되지 않은 상황이라면 어쩔 수 없는게 정설이다..

  Redis Blacklist 관리

  우선 기본적으로 토큰은 삭제할 수 없다. 그러나 이를 무효(Invalidate)할 수 없다는 뜻은 아니다. 사용자가 로그아웃을 하거나, 토큰이 탈취 되었음을 깨달았을 때 그러면 어떻게 해야 할까? Blacklist를 만들어 해당 사용자의 토큰을 비교하여 인증을 실패하도록 하면 된다.

  클라이언트 측에서 토큰 삭제

  서버 입장에서는 가장 간단한 방법이다.

우리는 어떻게 구현할 것인가???

• 로그인, 인증 가장 많이 자주 사용되는 방법이 첫 번째에 소개한 Expired Time을 짧게 하여 자주 Refresh를 발생시키는 방법이라고 한다. 그리고 Redis 로 Refresh Token을 관리한다. 나는 근 며칠간 공부하면서 가장 직관적으로 이해 되는 부분이 이 방법이라고 생각해서 이 방법이 좋을 것 같다고 생각한다.
• 로그아웃 여기서 이제 로그아웃을 어떻게 구현할 지 고민이 좀 되는데 Redis에 계속 정보를 요청하고 비교하는 작업이 들어간다면 서버에 부하가 심할 것 같다. 물론 우리가 토이 프로젝트로 MAU도 전혀 없지만 사용자가 1000만명이라고 가정한다면 어떤 방법이 좋을 지 다같이 고민해보면 좋을 것같다. 그래서 일단 내 생각은 client 측에서 GET /logout 으로 요청을 보내고 정상 응답 200 을 받으면 소지하고 있는 Access, Refresh Token을 삭제하는게 좋아보이는데 다들 어떻게 생각하시나요?

참고 링크

• MSA JWT https://meetup.toast.com/posts/239
• Invalidate JWT https://stackoverflow.com/questions/37959945/how-to-destroy-jwt-tokens-on-logout https://stackoverflow.com/questions/21978658/invalidating-json-web-tokens
• JWT 탈취 https://developer.okta.com/blog/2018/06/20/what-happens-if-your-jwt-is-stolen