OAuth란?
OAuth는 사용자 인증을 위한 기술 표준입니다. OAuth는 사용자 이름, 비밀번호 등의 실제 사용자 자격 증명을 공유하지 않고 한 서비스에서 다른 서비스로 권한 부여를 전달하기 위한 프로토콜입니다. OAuth를 사용하면 사용자는 한 플랫폼에서 로그인한 다음 다른 플랫폼에서 작업을 수행하고 데이터를 볼 수 있는 권한을 부여받을 수 있습니다.
쉽게는, 구글에 이미 사용자로 인증을 한 유저가 다른 서비스에서 구글의 자격 증명을 가지고 해당 서비스를 이용할 수 있는 기술이며, 최근의 웹 서비스에서는 소셜로그인, 간편로그인 등의 명칭으로 카카오, 네이버, 구글 등 많은 메가 웹서비스들이 OAuth를 통한 자격 증명 공유를 제공합니다.
더 쉬운 예로는, 집주인이 없을 때 방문자가 집에 와서, 집 주인이 실제 집 열쇠를 보내는 대신에 열쇠가 들어 있는 자물쇠함을 열 수 있는 임시 코드를 보내는 것과 같습니다. OAuth도 비슷한 방식으로 작동합니다. OAuth에서 애플리케이션 하나가 사용자의 자격 증명을 보내는 대신 다른 애플리케이션에 권한 부여 토큰을 보내 사용자에게 액세스 권한을 부여합니다.
OAuth를 구현한 이유
유저에게 간단한 로그인 방법이며, supabase를 활용하면 구현 또한 간편하기 때문에 구현했습니다. 또한, 실제 서비스가 운영된다고 가정했을 때, 일반 로그인보다 훨씬 간편한 방법이기 때문에 이탈율을 줄이고, 회원가입 성공율을 높일 수 있다는 장점도 있다고 생각되어서 OAuth를 구현하게 됐습니다.
구현 과정
Google Cloud Platform(GCP)의 사용자 인증정보와 supabase Authentication 내부의 provider로 GCP와 연동하여 인프라를 구축할 수 있습니다. (구글링으로 충분한 정보를 얻을 수 있고, 다른 추가적인 정보가 없기 때문에 과정은 생략하겠습니다.)
위와 같이 supabase client의 signInWithOAuth 메서드를 활용하고, provider로써 google을 지정해주면 사용이 가능합니다. options의 queryParams는 OAuth url로 이동 시, 추가적인 쿼리 파라미터를 추가하여 옵션을 설정할 수 있는 부분인데, 간단하게 access_type의 offline은 사용자가 직접 로그인하지 않아도, access token을 갱신하는 옵션이며, 로그인 상태를 계속 유지시킬 수 있는 옵션이며, prompt: consent는 이 전에 OAuth 로그인으로 인증 정보를 제공했더라도, Google 동의 화면을 계속해서 띄워주는 옵션이며, 서비스 내부에서 Google에서 가져오는 인증 정보의 변동이 있더라도, 로그인 시 동의 화면을 계속해서 띄워주기 때문에 추가적인 정보를 제공받는데 용이하기 때문에 설정했습니다.
유의사항
지금까지는 회원가입을 하게 되면 별도의 DB에 user 테이블 같은 유저 정보를 저장할 수 있는 테이블을 만들어 저장하고 사용하였으나, supabase에서는 인증과 인가를 담당하는 Authentication이라는 기능이 따로 존재하며, supabase에서 db를 생성하면 public schema에 생성되지만 Authentication은 미리 auth schema에 users 테이블에서 관리됩니다. auth schema의 속한 테이블은 구조를 변경할 수 없으며, supabase에서는 추가적인 유저의 데이터를 만들고 사용하기 위해서 따로 users 테이블을 생성하여 관리하는 것을 권장하고 있습니다.
이에 따라서, 추가적인 연동이 필요하며 추후의 글에서 db의 function과 trigger 구현 과정에서 자세하게 설명하겠습니다.
참고
https://www.cloudflare.com/ko-kr/learning/access-management/what-is-oauth/