땃쥐네

안녕하세요. 혹시 이 블로그를 보시고 있는 분이 있으실지는 모르겠습니다.결론부터 말씀드리면 현재 진행 중이였던 게시판 프로젝트는 중단하기로 했습니다. 처음 이 프로젝트를 만든 계기는 제가 이곳저곳에서 배운 기술들을한 프로젝트에 전부 때려박아서 기능 사용 경험을 늘려보자는 취지였습니다. 나만의 애플리케이션 아키텍처 설계, 무중단 배포, Spring Security, Jpa, Redis, 코틀린, Spring MVC, 그 외 기타 등등을 전부 한 프로젝트에 떄려박아서, 배웠던 기술들을 죽어있는 이론으로 만들지 말고 실제 사용 경험으로 만들자는 취지였죠.  하지만 프로젝트를 진행하다보니 초기 단계에 넣었던, 멀티모듈화 및 아키텍처 설계 부분이 프로젝트 진행이 장기화될 수록 저에게 큰 부담이 되었습니다. 간단한..

이전 글에서, 사용자의 소셜서비스 사용자 정보를 획득하는 것까지 수행했습니다.이제 이 정보를 기반으로 우리 서비스에 실제로 로그인 시키고 회원가입까지 해보겠습니다.1. 유즈케이스 계약package com.ttasjwi.board.system.auth.application.usecaseimport java.time.ZonedDateTimeinterface SocialLoginUseCase { /** * 소셜 연동 정보를 기반으로 액세스토큰, 리프레시 토큰을 얻어옵니다. * 만약 소셜 연동에 해당하는 회원이 없으면 회원을 생성합니다. */ fun socialLogin(request: SocialLoginRequest): SocialLoginResult}data class So..

지난 글에서는 사용자의 OAuth2 권한부여 요청이 들어왔을 때, 사용자를 실제 권한부여 엔드포인트(소셜 로그인 페이지)로 리다이렉트 시켜서, code를 발급받는 부분까지 진행했습니다. 이번 글부터는 사용자를 실제로 소셜로그인, 회원가입 시키는 작업을 진행해볼건데요.소셜 서비스의 사용자 정보를 획득하는 작업까지 해보도록 하겠습니다.1. 리다이렉트 받은 페이지: 다시 백엔드의 소셜 로그인 API를 호출   리다이렉트 받은 페이지입니다.제가 따로 프론트엔드 서버를 띄워두지 않았지만, 프론트엔드 측에서는 사용자가 이 페이지로 리다이렉트 되었을 때 다음 작업을 수행해야합니다.  1. 구글/네이버/카카오 측이 리다이렉트 시점에 보낸 파라미터 수집리다이렉트 된 페이지의 쿼리 파라미터에는 state, code, sc..

지난 글에서는 스프링 시큐리티 OAuth2 Client 연동을 위한 Client, Provider 설정을 구성했습니다.이번 글부터는 본격적으로 기능을 하나씩 구현해보겠습니다.1. 권한부여 요청 URL 구성해보기여기서는 예시로 구글을 들어보겠습니다. 구글 연동 로그인을 위해서는최종 사용자가 구글에게 '우리 서비스'가 자신의 특정 정보를 사용할 수 있어야한다는 승인을 해야합니다. 사용자는 결국 구글측의 어떤 엔드포인트를 호출해야합니다. https://accounts.google.com/o/oauth2/v2/auth 실제로 구글은 위의 엔드포인트를 통해 권한부여를 수행할 수 있도록 합니다.그런데 단지 저 요청만으로는 어느 서비스에게 권한을 부여해야하는 지 정보가 부족합니다. https://accounts.go..

간단하게 서비스의 사용자들의 편의를 위해 소셜 로그인 기능을 추가해보겠습니다.다만 소셜 로그인 기능은 구현과정이 약간 길어지다보니 글을 2-3개 정도로 쪼개서 진행해보겠습니다. 양해 부탁드립니다.1. OAuth2 인증 방식 흐름 예를 들어 구글 로그인을 생각해볼게요.여러분이 여태 다른 서비스를 이용해보시면서 그 서비스 사용시 Google 로그인을 하며id 와 pw를 직접 전달해본 적이 있나요? 보통 서비스는 그런식으로 구성되어 있지 않습니다. 해당 서비스를 믿고 id, pw 를 그대로 넘겼다가 그 서비스가 무슨 짓을 할지 모르는데그걸 냉큼 넘겨줘선 안 됩니다. 이런 신뢰성 문제를 해결하기 위해 도입된 것이 OAuth2 입니다.우리 서비스가 최종사용자의 승인을 얻고, 제3의 서비스로부터 최종사용자의 정보를..

로그인 기능을 통해 액세스토큰과 리프레시 토큰을 발급했습니다. 액세스토큰은 유효시간을 짧게 가지는 인증을 위한 토큰이고,리프레시토큰은 좀 더 유효시간을 길게 잡는 대신 인증을 위해 사용하지 않고, 액세스토큰 재갱신을 위해 사용하는 토큰입니다. 액세스토큰은 상대적으로 짧은 시간(제 기능 기준 30분마다)마다 무효화되다보니 리프레시 토큰을 통해 별도로 액세스토큰을 재발급할 수 있는 API가 필요합니다. 이를 위해 토큰 재갱신 API 를 만들어보도록 하겠습니다.1. 기능 개요사용자는 요청을 통해 리프레시토큰 값을 보내고 애플리케이션은 리프레시 토큰을 확인하여 유효하다 판단되면, 리프레시 토큰을 내려줘야합니다. 그런데 리프레시 토큰이 무한정으로 계속 발급될 수 있으면, 여러 곳에서 동시에 서비스에 접근하는 걸 ..

기존에는 로그인 하지 않은 사용자를 대상으로만 Api를 구현했습니다.이제 로그인 한 사용자를 대상으로 한 Api 들도 필요해질 것인데, 요청마다 사용자의 인증/인가가 필요해집니다. 지난 글에서 로그인 Api 를 구현하여 사용자에게 액세스토큰, 리프레시 토큰을 발급했습니다.매 요청마다 사용자에게 액세스토큰을 받고, 인증처리를 할 수 있도록 해보겠습니다. 여기서 스프링 시큐리티를 사용해보겠습니다.1.  스프링 시큐리티1.1 스프링부트 시큐리티스프링 시큐리티는 인증/인가 기능을 편리하게 구현할 수 있도록 스프링이 제공하는 라이브러리입니다. 여기서 더 나아가서 스프링부트 시큐리티(spring-boot-starter-security)를 사용하면, 인증/인가에 필요한 스프링 시큐리티 빈들이 자동구성으로 포함되어집니..

이번 글에서는 이전부터 미뤘던이메일 인증, 리프레시토큰 홀더의 Redis 저장 설정을 해보겠습니다.1.  Redis 레디스는 인메모리 데이터베이스의 대표적인 제품으로, 데이터를 메모리에 저장하는 특징이 있습니다.디스크에 데이터를 저장하는 관계형데이터베이스들보다 데이터 접근이 빠르기 때문에 주로 캐시로 많이 사용합니다. 127.0.0.1:6379> set key valueOK127.0.0.1:6379> expire key 10(integer) 1127.0.0.1:6379> ttl key(integer) 5127.0.0.1:6379> ttl key(integer) 3127.0.0.1:6379> ttl key(integer) -2127.0.0.1:6379> get key(nil)  또 레디스는 TTL(Time..