SpringBoot47 [Spring Boot] 34. JWT 인증 갱신처리 (3) 이제 JWT를 통한 인증처리의 마지막 단계입니다. Back-End에서 Access Token과 Refresh Token을 발급하여, Front-End를 통해서 개별 사용자 환경에 해당 Token들을 저장하는 로직을 구현하였고, 더 나아가 Front-End에서는 사용자의 Token의 Expiration을 확인하여 조건에 따라서 Token을 전달하는 로직까지 구현하였습니다. 중간에 Refresh Token에 대한 DB에 저장하는 로직 등 추가적인 내용도 여럿 있었습니다. 최종적으로 Access Token의 만료로 Back-End에 Refresh Token을 전달할 때, Back-End에서 처리하는 로직에 대해서 구현해 보도록 하겠습니다. 이를 위해서는 Front-End와 Back-End에 각 각 로직이 모두.. 2021. 4. 26. [Spring Boot] 33. JWT 인증 갱신처리 (2) 이번에는 저번시간에 이어서 JWT를 통한 인증 갱신처리하는 로직을 마저 구현하겠습니다. 지난번에 알아본 전체 동작 로직을 다시 생각해 보면, 아래와 같습니다. 사용자는 Google Signin Button을 통해서 Google OAuth로 인증을 수행하고, 연결되어 있는 API로 verify를 진행하게 됩니다. 이 부분은 지난번에 구현한 부분이기 때문에 생략하기로 하겠습니다. Back-End에서는 verification이 성공적으로 끝나면, JWT를 통한 Token을 생성하는데... 기존과 다르게 2가지 Token을 생성합니다. Access Token, Refresh Token이 그것입니다. Back-End에서는 이 중에서 Refresh Token을 사용자 e-mail 주소와 함께 DBMS에 저장합니다... 2021. 4. 24. [Spring Boot] 32. JWT 인증 갱신처리 (1) 지금까지 구현한 JWT를 통한 Google OAuth연동 구현과 관련하여, JWT Token을 사용자에게 잘 발급하여 인증체크 및 만료에 대해서 정상적으로 구현이 완료되었습니다. 하지만 현재는 Token의 Expiration기간이 최초에 설정되면 이 Token에 대한 유효기간이 만료되면 다시 로그인하여 Token을 발행해야하는 로직으로 동작하게 됩니다. 하지만, 이렇게 되면 사용자의 입장에서는 해당 web application이 아무리 좋은 정보를 제공한다고 하더라도 불편함이 더 크게 인식되어 접근을 꺼려하게 됩니다. 따라서, 정해진 절차에 따라서 Token이 만료가 되었을 경우 기간을 연장하여 재 발행하는 로직이 필요합니다. 이를 위해서 보편적으로 사용하는 방식이 Access Token과 Refresh.. 2021. 4. 23. [Spring Boot] 31. Google OAuth with JWT (3) 지난 시간에는 Back-End에서 생성한 Token을 Front-End로 전송하는 단계를 진행하였습니다. 이렇게 전달된 Token은 개별 사용자의 Browser내 Local Storage, Session Storage 혹은 Cookies에 저장하여 사용할 수 있도록 준비하는 것 까지 개발을 완료 했습니다. 이번에는 그 이후에 사용자가 Front-End를 통해서 Token을 header에 추가하여 API를 요청할 때, Token을 확인하고 유효할 경우 서비스를 제공하는 단계를 진행해 보겠습니다. 전체적인 그림은 이전에도 보셨지만 아래와 같고, /apis로 서비스 요청 + Token부터 그 이하에 대한 부분의 적용이 되겠습니다. 현재 사용자의 Local Storage에는 Back-End로부터 전달받은 Tok.. 2021. 4. 20. 이전 1 2 3 4 ··· 12 다음
