JWT + OAuth를 도입했을 때 테이블 구조와 로직에 대해 조언 좀 부탁드립니다.

Question

우선 자사 회원가입(이메일 + 비밀번호)을 지원하면서, 동시에 소셜 간편 회원가입도 지원하려 합니다. (Naver, Kakao, Google)그래서 테이블을 설계하는데 좀 문제가 발생하네요.우선 소셜로 회원가입을 하더라도, 이메일 정보는 필수로 받으려 합니다.그래서 Member 테이블을 아래와 같이 설계했어요id (pk)email (unique, not null)password (nullable)name (not null)nickname (not null)provider (nullable) => 자사 회원가입 회원일 수도, oauth를 통한 소셜 회원가입일 수도 있기 때문에 구분그리고, 소셜 회원일 경우에 provider_id라고 고유 식별값을 주는 거로 알고 있어서 이걸 별도의 테이블로 분리하긴 했습니다.Oauth라는 테이블로 따로 뺐고, 아래와 같이 설계했어요member_id (pk, member테이블의 id를 fk)provider (not null)provider_id (not null)이때, 기존 이메일+비밀번호 입력 시 인증 방식을 JWT를 사용하려 합니다.access_token은 클라이언트쪽에서 관리하게 하고, refresh_token만 서버쪽에서 일정 기간만 유지시키려 하고 있습니다. (mongo db)그리고 일정 기간(30일 정도)이 지나면, 로그인이 풀리게끔하고, 다시 로그인하게 처리하려 합니다.=> Q1) 해당 방법이 괜찮은가요? 아니면 refresh_token을 rdbms에 저장하고 관리하는 게 좋을까요?그런데 OAuth도 이러한 access token 및 refresh token을 이용한다고 하더군요그래서 원래 JWT로만 인증을 수행할 경우 Member 테이블에서만 refresh_token을 관리하면 됐는데,이 경우 mongo DB에 refresh token을 저장한다면 type같은 필드를 두고, normal인지 google인지 등 표현해줘서 일반JWT와 구분해주려 하고 있습니다.Q2) 그러나 만약에 Q1의 답변이 rdbms에서 refresh_token을 관리하는 게 좋다고 할 경우 Oauth 테이블에 refresh_token을 추가로 둬야 할지 고민입니다.이럴 경우 테이블 구조는 다음과 같아질 것 같습니다.Member(id, email, password, name, nickname, provider, refresh_token)Oauth(member_id, provider, provider_id, refresh_token)그런데 또 이렇게 테이블을 설계해보고 나니어차피 provider 값을 두 테이블에서 동일하게 관리하니까...차라리 그럴 거면그냥 Oauth를 별도의 테이블로 분리하는 게 아닌 Member 테이블 하나에서 관리하면 되지 않을까? 라는 생각도 듭니다.뭐 테이블을 설계하는 데에 있어, 정답은 없다곤 하지만, 최대한 보편적인 방법이 그만한 이유가 있겠구나 싶어서요.어떻게 처리해야 할지 몰라 고민되어 글을 작성하게 됐네요.위에 작성하면서 Q1, Q2로 궁금한 점을 명시하긴 하였으나, 다시 간략하게 정리해보겠습니다.JWT(자사 회원가입) + OAuth(소셜 회원가입) 두 가지를 지원할 때, 테이블을 분리해서 관리해야 하는지, 혹은 그냥 member 테이블 하나에서 다 관리하는지만약 분리해서 관리한다면, refresh_token은 어떻게 관리하는 것이 좋은지refresh_token은 유효기간 없이 계속 있는 것보단, 30일 정도 유효기간을 정해두는 게 보안상 좋다고 하던데, 이 떄문에 mongo_db에 저장할 생각을 하였는데 괜찮은 방법인지? (redis는 인메모리라 서버마다 다르게 관리되므로...)만약 mongo db가 별로라면, 별로인 이유가 궁금하고 대용으로 어디에 저장하는지, 만약 rdbms에 저장한다면 유효기간은 어떻게 설정하는지 (혹시 재로그인 할 때마다 다시 update 작업을 사용하는지 혹은 스케줄러를 이용하는지)이것저것 혼자 해보면서 저에게 맞는 답을 찾아보고도 싶지만,저보다 더 많은 경험을 해보신 분들의 시야와 생각을 배워보고 싶습니다.감사합니다.

개발잡부 · Answer

네이버를 예를 들어봅시다Oauth 인증을 통해 네이버한테 JWT Token을 받죠?이걸 그대로 사용하지말고, 이 JWT Token을 이용해서, 다시 네이버에게 회원정보조회 api를 요청합니다.그 결과값으로 일반로그인 할때와 동일한 JWT Token을 만들어서 Front에게 주면 됩니다.그리고 (redis는 인메모리라 서버마다 다르게 관리되므로...) <-- Redis Cluster에 대해 공부해보시기 바랍니다유효기간은 Redis의 TTL에 대해 공부해봅시다...

스타이너 · Answer

저장위치는 RDB든 MONGO든 어디든 상관 없는데멤버 테이블에 굳이 token값을 넣을 필욘 없다고 보여지구요 token도 결국 취소시키거나 재발급 받는 로직도 태우고 그래야되서 별도로 관리 하시는게 맞을듯요... 나머지 궁금증은 다른분들이 답변해주실거라 믿습니다. (__)

감독님테스트가하고싶어요 · Answer

OAuth 에서 resource server 에 접속하는데 사용되는 access token을 자사 서비스의 인증방식인 jwt - access token으로도 사용한다는건가요?이렇게 서비스하는 곳이 있는지는 모르겠지만, 그게 좋은 방법인지는 잘 모르겠네요. 그냥 어떤 방식이든 로그인 성공하면 자사에서 jwt 새로 발급해주는게 더 개발/관리가 더 용이할 것 같은데요.redis 가 인메모리 방식인거랑 서버마다 다르게 관리되는건 무슨 연관인지? 이 부분은 좀 더 공부해보시는게 좋을 것 같네요.member에 provider 관련 컬럼은 굳이 필요없을거같고요(Member, Oauth 조인만 해도 구분이 가능할 것 같네요)그냥 회원가입 이후에도 마이페이지 등에서 다른 간편인증과 연동시키는 기능을 제공하는 서비스들이 대다수라 더더욱 필요없어보입니다.가입 방식과 상관 없이 한개의 member로 관리하는게 일반적인 방법일 것 같네요.ttl을 지원하지 않는 db를 사용하고싶다면(굳이굳이굳이) 만료일도 같이 저장하면 될 것 같네요.

마카롱먹는수달 · Answer

두 토큰은 클라이언트에서 갖고 있습니다.1) 접속 토큰을 서버에 전달 했을 때 유효성을 체크하고, 만료 된 경우 만료 응답 값을 리턴 합니다.2) 클라이언트(재발급(리프레쉬)토큰)에서 리프레쉬 발행API를 호출합니다.3) 서버에서는 리프레쉬 토큰 유효성 체크하고 새로운 접속 토큰/재발급(리프레쉬) 토큰을 전달합니다.* DB에 저장 하는 이유는 서버가 재부팅 됐을 경우 대비(서버 메모리 저장 사용x)멤버/Oauth/소셜 테이블은 별도로 분류하는게 좋아보입니다.(멤버는 1개/Oauth는 인증 내역(N개또는 1개)/소셜 테이블은 N개으로 관리)

JWT + OAuth를 도입했을 때 테이블 구조와 로직에 대해 조언 좀 부탁드립니다.

4개의 답변

Q&A 목록