땃쥐네

지난 글에서는 스프링 시큐리티 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..

이번 글에서는 지난 글에서 설계해둔 로그인 기능에서, 마저 적용하지 못 한 JWT 기술을 적용해보겠습니다. 1. JWT 의존성 추가enum class Dependencies( private val groupId: String, private val artifactId: String, private val version: String? = null, private val classifier: String? = null,) { // kotlin KOTLIN_JACKSON(groupId = "com.fasterxml.jackson.module", artifactId = "jackson-module-kotlin"), KOTLIN_REFLECT(groupId = "org.je..

회원가입 기능을 구현했으니, 이어서 로그인 기능을 구현해보겠습니다.1. 로그인 개요 - 세션과 토큰HTTP는 기본적으로 무상태 프로토콜입니다. 기존 사용자가 누구인지 HTTP 자체 사양만으로는 기억할 수 없어요. 그래서 존재하는 기능이 로그인입니다.사용자가 아이디(또는 이메일), 패스워드를 전달하고, 이후에 서버에 사용자가 다시 요청을 보낼 때는 사용자가 누구인지를 기억하도록 하기 위한 작업입니다. 그런데 서버 입장에서는 사용자가 누구인지 어떻게 기억하고 관리할까요? 1.1 세션방식 첫번째로 세션방식이 있습니다. 가장 많이 사용되는 방식인데요.한번 로그인 하면 서버는 사용자에게 sessionId 에 해당하는 쿠키를 발급하여, 사용자가 계속 요청을 할 때마다 쿠키를 보내게 합니다. 쿠키에 기입된 sessi..

이메일 인증 기능을 구현했으므로, 이어서 회원가입 기능을 구현해보겠습니다.1. 표현 계층(Api 모듈)@RestControllerclass RegisterMemberController( private val useCase: RegisterMemberUseCase, private val messageResolver: MessageResolver, private val localeManager: LocaleManager,) { @PostMapping("/api/v1/members") fun register(@RequestBody request: RegisterMemberRequest): ResponseEntity> { // 애플리케이션 서비스에 요청 처리를 위임 ..