#17 fastapi-users를 써서 OAuth2를 적용해보았다!

이번 글에는 fastapi-users의 oauth2인증방식에 대해서 더 자세히 다루고 싶어서 제목을 "fastapi-users의 OAuth2 인증방식"로 했는데, 귀찮아서 바로 "fastapi-users를 써서 OAuth2를 적용해보았다!"로 바꿨습니다. 😅
서브 모듈인 fastapi_users_db_sqlmodel가 좀 오래된것 같아서 진짜 간단한 업데이트를 PR했는데.. 왠지 느낌이 쎄하다.

 

이 서비스에 소셜 로그인을 도입하고 싶어서 여러 라이브러리를 전전하던 중 fastapi-user를 알게되었다.

그래서 처음 쓰는게 다 그렇듯 뇌빼고 구글 소셜 로그인을 도입 했는데, 의문점이 생겼다.

주요 의문점은 “소셜 로그인 기능을 사용하는데 왜 회원가입/로그인 기능을 구현해야 하지?”라는 것이였다.

 

일단 OAuth2의 방식에 대해 일단 알아보았다. 

대충 외부에서 인증을 대신 해준다는 것만 알고 있었다.

그래서 아래 글을 봤다. (진짜 이 글 최고다 기~가 막히게 설명하는데 나도 잘명 잘 하고 싶다)

https://hudi.blog/oauth-2.0/

 

원래 jwt는 …

1. 클라이언트가 서버에 인증정보(아이디, 비번)을 보낸다.
2. 서버는 인증 토큰인 access token을 클라이언트에게 보낸다.
3. 클라이언트는 이 토큰을 쿠키나 브라우저의 로컬 스토리지에 저장한다.
4. 나중에 인증이 필요한 요청에 같이 싸서 보낸다.

 

OAuth2도 비슷하다. 

1. 클라이언트가 서버에 로그인 하고 싶다고 한다.
2. 서버는 인증 서버에 로그인 좀 대신 해달라고 요청한다.
3. 인증 서버는 클라이언트에게 로그인 주소를 보낸다.(당연히 서버를 경우해서)
4. 클라이언트는 인증한다.
5. 클라이언트는 그에 대한 대가로 인증 코드를 받는 순간 호호로록 서버로 인증코드 보낸다.
6. — 여기서부터는 jwt랑 같다. —
7. 서버는 인증 코드로 인증 서버로 보낸다. (서버는 클라이언트 대신 인증한 것이고 유저 리소스에 접근할 수 있다)
8. 인증 서버는 인증 토큰인 access token을 서버에게 보낸다.

OAuth2가 해주는 일은 여기까지고, 유저의 인증이 끝나지 않았다.

앞서 언급했던 글에 있던 다이어그램을 잘라보았다. 

(지금 로그인 대용으로 하는 것이지 리소스 제공을 하기 위해 OAuth2을 하는건 아니까)

 

이 다음일을 fastapi-users가 해준다.

등록된 유저가 없으면 회원가입을 하고 로그인을 진행해서 

백엔드 객체의 전략에 따라 토큰을 발행하던 세션 아이디를 주던지 알아서 해준다.

 

이 이유 때문에 소셜 로그인 기능만 사용한다고 해도 회원가입/로그인을 구현해야 한다.