Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEAT] OAuth 사용자 인증 도입 #794

Open
3 tasks
zangsu opened this issue Oct 15, 2024 · 5 comments
Open
3 tasks

[FEAT] OAuth 사용자 인증 도입 #794

zangsu opened this issue Oct 15, 2024 · 5 comments
Assignees
Labels
feature 기능 추가

Comments

@zangsu
Copy link
Contributor

zangsu commented Oct 15, 2024

📌 어떤 기능인가요?

OAuth 2.0 을 사용한 사용자 인증을 도입한다.

회의를 통해 #779 작업을 OAuth 도입으로 전환

📜 작업 상세 내용

  • OAuth 회원가입 구현
  • OAuth 로그인 구현
  • 일반 회원가입 제거

⏳ 예상 소요 시간 (예상 해결 날짜)

5일 소요 (10/20 15:00)

@zangsu zangsu added the feature 기능 추가 label Oct 15, 2024
@zangsu zangsu added this to the 6차 스프린트 🦴 milestone Oct 15, 2024
@zangsu zangsu self-assigned this Oct 15, 2024
@zangsu zangsu changed the title [FEAT] Oauth 사용자 인증 도입 [FEAT] OAuth 사용자 인증 도입 Oct 15, 2024
@zangsu
Copy link
Contributor Author

zangsu commented Oct 15, 2024

OAuth 의 로그인 동작 간단 설명!

OAuth 는 3자의 통신 과정으로 진행됩니다.

통신 참여 대상:

  • 어플리케이션 서버 / Client (이하 코드잽)
  • 사용자 / Resource Owner (이하 만두)
  • 인증 서버 / Authentication Server & Resource Server (이하 구글)
  1. 만두가 OAuth 로그인을 선택
  2. 코드잽은 구글 로그인 창을 제공해 줍니다.
  3. 만두가 구글에 로그인 요청을 보냅니다.
  4. 구글은 만두에게 Authorization Code (임시 비밀번호라고 생각하면 됩니다.) 를 발급해 주며 코드잽으로 리다이렉션 시킨다.
  5. 만두는 코드잽의 정해진 URL 로 리다이렉션을 하면서 Authorization Code 를 코드잽에게 알려준다.
  6. 코드잽은 구글에게 Authorization Code를 전달하고 Access Token 을 발급받는다.

Access Token 은 코드잽이 구글에게 유저 정보를 조회 (또는 다른 작업) 하기 위해 존재한다고 하네요~
(저는 처음에 만두가 코드잽에 접근하기 위해 사용하는 줄 알았음 ㅎㅎ 그게 아니래용~)

그럼 우리는??

위의 설명에서는 프론트엔드와 백엔드가 뭉뚱그려 설명되어 있는데요.
우리는 프론트의 역할과 백엔드의 역할이 엄연히 구분되어야 합니다.
이에 대해서는 조금 더 이야기를 해 보아야 겠지만, 선배 기수인 후디의 블로그 글을 참고해 볼 수 있을 것 같아요~

참고 자료

깃짱의 OAuth 2.0의 개념과 과정

@zangsu
Copy link
Contributor Author

zangsu commented Oct 15, 2024

작업 범위

이번 개발에서는 Refresh Token 을 고려하지 않습니다.
그 이유는 다음과 같습니다.

  1. "사용자 식별"을 위해 꼭 필요한 과정이 아님
  2. 코드잽의 서비스가 보안이 그렇게까지 중요한 서비스는 아님

하지만, 결국 Access Token 이 탈취 당하거나 하는 등의 문제를 해결하기 위해선 최종적으로 Refresh Token 의 사용 방법에 대해 고민이 필요할 것 같습니다.

@zangsu
Copy link
Contributor Author

zangsu commented Oct 15, 2024

로그인 유지 방법

로그인을 할 때는 Access Token 을 사용하더라도, 로그인을 유지할 때는 지금과 동일하게 CredentialManager, CredentialProvider 를 통해 쿠키 값을 지정할 수 있을 것 같습니다.

이렇게 하면 Access Token 을 서버에 저장할 필요 없이 기존 방식대로 로그인 유지가 가능합니다.

@zangsu
Copy link
Contributor Author

zangsu commented Oct 15, 2024

DB 변경

OAuth 에서는 기본적으로 제공해 주는 사용자의 고유 ID 만을 사용할 계획입니다.

새로 생길 테이블 :

(fk) member_id identify_id
1 01021

-> 01021 이라는 고유 ID 는 1번 멤버로 식별 가능한 값이다.

테이블이 하나가 추가되면 다른 OAuth 서비스를 추가로 확장하더라도 기존 테이블의 변경이 없기에 롤백이 쉽습니다.
또한, OAuth 서비스가 늘어나면서 특정 테이블이 비대해 질 불편함도 예방할 수 있습니다.

@zangsu
Copy link
Contributor Author

zangsu commented Oct 15, 2024

고려 사항

OAuth 관련해서 알아보다가 방끗에서 받은 피드백을 알게 되어 공유드려요!
OAuth 를 하나만 사용하면 해당 OAuth 서비스에 강한 의존성이 생깁니다.
(ex. 카카오 서비스가 문제가 생기면 카카오 로그인을 사용하는 사람이 서비스 자체를 이용하지 못함)

그래서 OAuth 도 두 개 이상 붙이는 것이 권장되며, 일반 로그인도 함께 제공하는 이유가 이렇다고 해요.
(아마 티스토리는 그 자체가 카카오에서 제공하는 서비스라서 카카오 로그인만 사용하게 하는 것 같기도??)

오늘 결정되었던 "Google 하나만 붙이고 일반 로그인은 점차 줄여나가자" 라는 방향에 대한 문제인 것 같아서 일단 공유 드립니다.

일반 로그인을 그대로 유지한 채로 나중에 여유가 생기면 Email 인증을 추가로 넣는 방법은 어떠실까요?
일반 회원가입은 코드를 삭제하지 않고 잠시 숨겨두었다가 다시 살리면 좋을 것 같은데요.
Email 인증도 제가 욕심이 나서 제안 하는 것이라 "작업 강도" 가 걱정이라면 제가 구현해도 좋으니 편하게 정책적으로만 의견 주시면 감사하겠습니다~

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature 기능 추가
Projects
Status: Todo
Development

No branches or pull requests

1 participant