회원가입 시 교수 데이터 저장 방식 결정

[sunohkim]

맨 처음 회원가입할 때 교수 데이터를 db에 저장하는 방식에 대해 고민 중입니다. 우선 Professor 테이블에 들어가야 할 정보는 교수 email, oauthId(구글 로그인 시 sub에 해당), 닉네임 등이 있습니다.
저는 교수 데이터를 db에 저장하는 시점은 교수가 닉네임과 프로필 사진을 설정한 뒤 '회원가입하기' 버튼을 누른 시점이어야 한다고 생각합니다. 그러나 해당 버튼을 누른 시점에는 클라이언트와 서버 모두 oauthId와 email 정보를 가지고 있지 않기 때문에, db에 oauthId와 email 정보를 정상적으로 함께 저장하기 위한 방법이 필요합니다.

1. 구글 로그인 시 발급한 oauthId와 email 정보를 쿠키 형태로 클라이언트에게 임시로 발급하고, 이후 클라이언트가 '회원가입하기' 버튼을 누를 때 해당 쿠키를 함께 서버에 전달하기
2. 세션으로 서버 측에서 oauthId와 email 정보를 보관한 뒤, 사용자가 '회원가입하기' 버튼을 눌렀을 때 세션에서 oauthId와 email을 가져와서 닉네임&프로필 사진 정보와 함께 db에 저장 (이럴 경우 클라이언트의 요청과 세션에 들어 있는 정보가 동일한 사용자인지를 검증하는 로직이 필요합니다.)
3. 먼저 access 토큰을 받으면서 함께 받았던 oauthId와 email 정보를 저장한 뒤, 회원가입 페이지에서 교수가 닉네임과 프로필 사진을 설정하면 그 때 해당 아이템에 닉네임과 프로필 사진을 추가

1번 방식은 서버 부하를 줄일 수 있고 구현이 간단하지만, oauthId를 클라이언트에게 줘야 한다는 부담과 탈취 위험이 있습니다.
2번 방식은 보안 측면에서 좋지만, 서버에 부담이 되고 구현 난이도가 더 높습니다.
3번 방식은 가장 간편하지만, 교수가 닉네임 설정을 하지도 않았는데 db에 데이터가 등록되기 때문에 위험합니다.

어떤 방식이 적합할지 의견 주시면 감사하겠습니다!

[uri010]

말씀해주신 방법들에 대한 제 생각입니다.

1. 쿠키에 oauthId와 email 담아서 전달
   -> 보안상 위험할 수도 있고, 클라이언트가 oauthId를 알아야 할 필요가 없다고 생각합니다.
2. 세션을 이용해 oauthId와 email을 기억
   -> 서버가 사용자의 로그인 정보를 일정 시간 동안 유지해야 하는 부담이 있습니다.
3. 로그인시 oauthId와 email만 저장
   -> 사용자가 이름과 프로필 이미지를 설정하지 않으면 null값이 남게 됩니다. 이후 로그인할 때 닉네임이 비어 있으면 서비스 오류로 생각될 것 같아요.

✅ 대안 : 디자인 변경

현재 디자인은 아래 사진과 같습니다. 이 방식은 사용자가 정보를 입력해야만 회원가입이 완료된다는 인식을 줍니다. 저희가 현재까지 구현한 로직상 구글 로그인이 성공하면 자동으로 회원가입이 되도록 되어 있기 때문에 차라리 디자인을 바꾸는 걸 제안드립니다!

개선 방안

1. '회원가입하기' 버튼 보다는 '수정하기' 같은 이름으로 바꾸는 방법
2. 로그인 성공시 회원가입이 완료되었다는 페이지만 보여주고, 회원 정보 수정은 마이페이지에서만 하는 방법

프론트분들은 어떻게 생각하시는지 궁금합니다..! @DrCloy @wwweric12

[wwweric12]

제가 생각한 의견입니다.

1. 구글 로그인 시 발급한 oauthId와 email 정보를 쿠키 형태로 클라이언트에게 임시로 발급하고, 이후 클라이언트가 '회원가입하기' 버튼을 누를 때 해당 쿠키를 함께 서버에 전달하기
   의견: 구글로그인을 완료후에 쿠키를 발급받고 이후 회원가입하기 버튼을 눌러서 한번만 보내고 쿠키를 삭제했을때 괜찮아 보이긴합니다. 또한 보안적으로도 HttpOnly설정을 통해 사용자가 확인할 수 없기때문에 괜찮을거 같습니다.
   다만 쿠키를 발급만받고 회원가입하기 버튼을 누르지 않고 서비스를 떠났을때 문제가 생길 위험도 있다고 생각이 듭니다.

2. 세션으로 서버 측에서 oauthId와 email 정보를 보관한 뒤, 사용자가 '회원가입하기' 버튼을 눌렀을 때 세션에서 oauthId와 email을 가져와서 닉네임&프로필 사진 정보와 함께 db에 저장 (이럴 경우 클라이언트의 요청과 세션에 들어 있는 정보가 동일한 사용자인지를 검증하는 로직이 필요합니다.)
   의견: 이 부분은 서버에서 처리하기가 매우 어려울거 같습니다....

3. 먼저 access 토큰을 받으면서 함께 받았던 oauthId와 email 정보를 저장한 뒤, 회원가입 페이지에서 교수가 닉네임과 프로필 사진을 설정하면 그 때 해당 아이템에 닉네임과 프로필 사진을 추가
   의견: db에 저장하지말고 서버 메모리에 저장해 놓은다음에 일정시간 지나도 닉네임과 프로필 사진에 대한 요청이 없다면 삭제하는 방법도 괜찮아 보입니다.

4. 디자인변경
   의견: 유리님이 말씀하신 의견으로 디자인변경은 개발의 편의성으로 봤을때는 가장 간편한 방법이라고 생각합니다.
   하지만 처음 회원가입할때 프로필설정없이 따로 마이페이지로 들어가서만 프로필 수정을 할 수 있다면 사용자관점에서 불편하다고 느낄거같습니다.
   그래도 현재 개발적으로 중요한점이 이부분이 아니기때문에 오래걸린다면 디자인 변경을 해도 될거같습니다.

결론

잘 모르지만.. 서버가 부담이 없으면 3번으로 가는게 가장 좋아보이긴합니다..
만약 부담이라면 4번으로 가도 상관없을거 같습니다!!

[DrCloy]

일단 저는 회원가입 할 때는 사용자 이름이나 프로필 사진을 입력받지 않고 이후 서비스 내에서 회원 정보 수정을 통해 수정하게 하는 플로우는 적절하지 않다고 생각합니다. 사용자 입장에서는 처음에 이름과 프로필 사진을 입력하는 과정이 없다면 이름이나 프로필 사진을 수정할 수 있다고 생각하지 않을 가능성이 높다고 생각합니다.

따라서 저는 회원가입 과정은 필요하다고 생각하며, 입력받아야 할 사용자 이름과 프로필 사진에 대해서는 빈 값으로 두고 나머지는 기존의 형식대로 JWT를 발급하여 사용하는 것이 좋을 거 같다고 생각합니다. 일단 회원가입 시 사용되는 JWT는 회원가입 시에만 사용되는 일회용 토큰이므로 유출되더라도 서비스를 사용하는데에는 사용할 수 없고 사용자가 회원가입을 끝냈다면 해당 토큰을 사용할 수조차 없어 보안적인 문제는 없다고 생각합니다. 또한 sub 값이나 email 자체는 유출되더라도 큰 문제가 없는 값들이고, 애시당초 JWT를 사용한 시점부터 이 값들은 언제든지 유출될 수 있는 값들이라 유출에 신경쓸 필요는 없어 보입니다.

[uri010]

제가 개선 방안으로 제시한 1번의 경우는 처음에 이름과 프로필 사진을 수정할 수 있도록 사진과 같이 보여주되, Google에서 받아온 사용자 정보를 넣은 상태에서 보여주자는 의미였습니다. 이름이나 프로필 사진 수정이 가능하다는 사실은 해당 방식을 사용하면 충분히 보여줄 수 있을 거라고 생각해요.

저도 다시 생각해보니 회원가입 과정 자체가 필요하다고 생각합니다.
근데 말씀하신 "입력받아야 할 사용자 이름과 프로필 사진에 대해서는 빈 값으로 두고 나머지는 기존의 형식대로 JWT를 발급하여 사용" 부분에서 기존의 형식대로 JWT를 발급하고 DB에 oauthId와 email 값만 넣어둔다면 회원가입이 되지 않았음에도 해당 JWT 토큰으로 로그인이 필요한 서비스에 접근할 수 있게 됩니다.

이를 위해 추가적으로 JWT 토큰에 회원가입 여부 적어줘서 확인하는 과정이나 회원가입 만을 위한 JWT 토큰을 발급하는 과정이 필요할 것 같습니다.
아마 "회원가입시 사용되는 JWT"라고 언급하신게 비슷한 의미인 것 같은데 "기존의 형식대로 JWT를 발급" 뒤에 나오는 말이라 제가 이해한게 맞는지 잘 모르겠습니다😅

[sunohkim]

만약 회원가입 과정이 필요하다면, 아래와 같은 구조로 변경이 필요할 것 같습니다.

1. 구글 로그인 시 회원가입 페이지로 넘어감과 동시에, 사용자에게 <oauthId, email>을 담은 쿠키 전달 (단, 이 쿠키는 기존 로그인 세션 유지에 사용한 jwt 쿠키가 되어서는 안 된다고 생각합니다. 해당 사용자는 아직 로그인하지 않았기 때문입니다. 따라서 용도가 다른 별도의 쿠키를 만들어야 할 것 같습니다.)
2. 사용자가 '회원가입하기' 버튼을 누르면 <닉네임, 프로필사진> 정보를 담은 HTTP 요청과 함께 <oauthId, email>을 담은 쿠키가 서버 측으로 전송
3. 서버 측에서 회원가입 절차를 진행한 뒤, database에 <oauthId, email, 닉네임, 프로필사진> 정보를 등록

[uri010]

저도 선오님이 생각하신거랑 똑같이 생각했습니다!!

[DrCloy]

회원가입용 JWT를 발급할 때는 DB에 데이터는 저장하는 것이 아닙니다!!

간단하게 순서를 정리하면

Access Token으로 사용자 정보 호출 -> DB에 oauthID 있는지 확인 -> 없으면 가져온 사용자 정보의 oauthId, email & 나머지는 빈 값으로 JWT 생성 -> 사용자에게 회원가입 URL과 JWT 전달 -> 사용자가 회원 정보 입력 후 회원가입 API 호출 -> 입력받은 값 + JWT 값으로 회원 정보 생성 후 DB에 저장

입니다!!

기존의 JWT를 발급하는 것과 같은 방식으로 회원가입용 JWT를 발급받아 사용하고, 다른 API에서는 JWT의 payload에 빈 값이 있으면 인증이 안 되는 것으로 처리하면 회원가입할 때만 사용할 수 있는 JWT를 만들 수 있을 거 같습니다. 보안 상의 이슈가 걱정된다면 회원가입용 JWT 서명 키를 따로 둔다던가, payload에 일단 JWT에서 사용하지 않는 항목을 추가하고 다른 API에서 해당 항목 있는지 확인하는 로직을 추가한다면 괜찮을 거 같습니다!!

[sunohkim]

답변 감사합니다!