[TIL] 22.08.03 WED

seongminn·2022년 8월 5일
0

TIL

목록 보기
3/11
post-thumbnail

💻 HACKATHON

이번 해커톤 기간 동안 많은 시도를 해보았고, 그만큼 부족한 부분이 많다는 것을 깨달았다. 코드를 리팩토링 하고 구현하지 못했던 부분을 채워가면서 배웠던 내용을 정리하고자 한다.

회원가입 & 로그인

로그인 방식에는 크게 두 가지가 있다.

Session
JWT

세션을 이용한 방식은 브라우저의 쿠키에 세션 id를 발급하고, 매 요청마다 브라우저의 쿠키를 검증하여 세션 id를 통해 사용자를 인증한다.

JWT를 이용한 방법은 세션 방식과 유사하게 토큰을 활용한다.

이번 미니 해커톤 프로젝트에서는 JWT 방식을 활용하여 유저 계정을 관리해보았다.

JWT

JWTJason Web Token의 약자로, 인증에 필요한 데이터가 암호화 되어 있는 토큰을 말한다.

JWT 토큰은 Header, Payload, 그리고 Signature까지 세 가지 영역으로 나뉘는데, Header에는 해쉬를 위해 사용되는 함수 정보가, Payload에는 암호화 하고자 하는 정보가 저장되어 있다. 그리고 Signature에는 헤더에 정의된 함수를 통해 암호화 된 정보가 들어있다. Signature에 저장된 비밀 값은 오직 서버만 알고 있다. 그래서 유저 APayload에 저장된 id를 유저 Bid로 바꾼 뒤 인코딩하여 서버로 보낸다 하더라도, Signature의 정보는 유저 APayload를 기반으로 암호화 되었기 때문에 서버는 이를 유효하지 않은 토큰으로 간주할 것이다.

refresh & access

이렇게 JWT 토큰으로 로그인을 하게 되면 사용자는 두 개의 토큰을 발급받는데, 하나는 Refresh Token이고 다른 하나는 Access Token이다. 당연하게도 이 둘의 역할은 다르다.

세션을 이용한 방식과 다르게 JWT는 한번 발급하면 토큰을 다시 회수할 수가 없다. 그래서 역할이 다른 두 개의 토큰을 발급하는 것이다.

실질적으로 인증/인가를 위해 사용되는 것은 Access Token이다. access token은 일정 시간이 지나면 만료되는데 refresh token에 비해 수명이 짧다. access token이 만료되면 refresh token을 서버로 보내 새로운 access token을 발급받는다. 결국 Refresh Token은 서명과 관계 없이 access token의 재발행만을 위해 존재한다.

토큰 저장

그렇다면 토큰은 어디에 저장해야 하는 것인가?

해당 블로그에 정리된 내용에 따르면

refresh tokenlocal Storage에, access tokenCookie에 저장한다.
• 요청 헤더에는 access token을 넣는다.
access token이 만료되면 refresh token을 가져와 새로운 토큰을 발급받는 요청을 한다.

위와 같다.


마무리

아직까지 refresh tokenaccess token을 별도로 제공받지는 못하고 있다. 그래서 백엔드를 담당한 팀원 분께서 코드를 수정하는 중이다.

나중에 토큰을 서버 측에서 refreshaccess를 정상적으로 발급할 수 있게 되면 소스 코드도 올려보도록 하겠다.


--

참고 사이트

🙇‍♂️ https://hololo-kumo.tistory.com/236
🙇‍♂️ https://velog.io/@tsi0521/%EB%A1%9C%EA%B7%B8%EC%9D%B8-%EB%B0%A9%EC%8B%9D%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90

profile
돌멩이도 개발 할 수 있다

0개의 댓글