이번주 목표
- refreshToken
- graphql이 사실은 Rest-api
- Async-await 를 for문에서 쓰면 안된다고? promist.all
- 자꾸 새로 만들말고 메모해놓기 Memoization
- 내사이트에서 모바일에서도 보고 싶어 @media
오늘 목표
- refreshToken
1. refreshToken
redis가 아닌 토큰에 저장했던 방식을 썼음
토큰의 원리를 이용해서 객체로 데이터를 저장하고
토큰을 암호화해서 가지고 있다가 복호화해\서 조회했던것
인증(Authentication) 과 인가(Authorization)을 이용해서
accessToken을 주고 받았음
accessToken을 탈취당할 경우 jwt로 들어오면 db에서는 정보를 줄 수밖에 없음
특정ip를 저장하거나 할수가 없고 토큰만을 복호화해서 확인할 뿐이다.
그렇기떄문에 탈취가 되면 개인정보가 위험해진다
그래서 30분에서 1시간 단위로 토큰 만료를 잡는다. (현재 우리 서버는 1시간 단위)
토큰이 만료되면 수동적으로 로컬스토리지를 비워줘야했다
이제는 리프레쉬 토큰을 이용해서 좀더 편하게 웹을 확인해보자!!
인증 과정
브라우저에서 로그인 인증을 하게 되면 백에서는 jwt를 생성했다.
그때 jwt를 두개를 만드는데 accessToken과 refreshToken 두개이다.
1.accessToke : 30분에서 1시간 유지
2.refreshToken : 2주에서 8주 유지
백에서는 jwt를 생성하고 브라우저로 다시 정보들을 보내주는데
payload에는 accessToken
cookie에는 refreshToken(httpOnly,secure)를 담아 보내줬다.
그렇게 받은 데이터들은 브라우저에서 받아서
accessToken은 state에 담고 refreshToken은 그대로 쿠키에 담아둔다.
인가 과정
name이나 price등 키와 값을 담아 beare accessToken에 담아 백으로 보낸다.
인가로 보내진 데이터들을 jwt로 복호화하고 db로 정보들을 보낸다.
그때 만약 accessToken이 만료가 되어 db에 보낼수 없으면
에러 메세지(Error: Unauthenrticated)를 보낸다.
브라우저로 돌아온 에러메세지는 apollo-setting 설정해둔
onError로 graphql에서 에러가 발생 되었을 때 그 에러를 캐치하는 것이다.
silent-auth 조용한 인증
1. onError 캐치
2. accessToken을 refresh 토큰을 이용하여 재발급 받음
- restoreAccessTokne
-
재발급 받은 accessToken을 프론트로 보내줌
-
로큰을 갱신?하여 마지막 실패 쿼리를 재시도 한다.
엄청 빠르게 처리가 되기에 유저가 느끼기엔 별다른 느낌을 받지 않지만
뒤에서는 많은 과정을 거치게 되는 것
이렇게 accessToken 인증 만료의 오류는 해결이 되고
리프레쉬 토큰이 만료가 된다면...?
방법 없음 새로 발급 받아야함!
refreshToken 실습
app.tsx의 apollo setting에 onError관련 로직 생성
토큰이 빠르게 만료되는 테스트용 graphql을 이용해서 연습할 예정
restoreAccessToken
로그인을 하고 쿠키를 보면 리프레쉬 토큰을 확인 할 수 있음
app.tsx의 apollo의 업로드 링크 부분을
http가 아닌 https로 되어있는지 확인한다.
그리고 headers에 credentials: "incluede"를 설정해준다.
이렇게 accessToken과 refreshToken을 각각 확인할 수 있다.
refreshToken은 httpOnly이기 때문에 콘솔로 확인하거나 브라우저에서 따로 조작을 할수가 없기에 안전성이 높다.
apollo setting 에서 뮤테이션을 보내야하는데 되지않음
apollo setting 하위내에서만 gql 즉 뮤테이션을 쓸수가 없음
그럴땐 뮤테이션을 쓸 수 있는 라이브러리를 이용해야함
https://www.npmjs.com/package/graphql-request
이렇게 operation을 이용해서 context의 headers 부분을 바꿀 수있다.
2. graphql의 실체
이제 국내에도 많이 도입되고 있는 graphql
graphql-request 라이브러리를 사용해
restoreToken API를 요청하는 코드를 보면
Axios를 이용한 Rest API 요청 형태와 비슷함
그건 GraphQL도 사실은 Rest-API의 일종이기 때문이다
- axios를 활용한 Rest API 게시글 조회, 등록 방법
// 게시글 조회
axios.get("API 주소")
// 게시글 등록
axios.post("API 주소", { 데이터 })// 게시글 조회
axios.get("https://koreanjson.com/posts/1")
// 게시글 등록
axios.post(
"https://koreanjson.com/boards",
{ writer: "철수", title: "제목!!", contents: "내용!!" }
)
Rest API는 필요한 기능 별로 서로 다른 endpoint를 가지고 있는데
서비스의 규모가 커질수록 endpoint의 수가 많아지게 되었고
graphql이라는 하나의 endpoint에 모든 API를 통합하는 방식이 개발된 것
axios.post("[API 주소]/graphql", {
aaa: "GraphQL 요청"
})
- GraphQL의 query와 mutation 모두 post 방식으로 데이터가 요청
- Rest-API의 단점을 해결
언더페칭 (Under Fetching)
- 언더 페칭은 필요한 데이터보다 적은 양을 가져오는 것(Fetching)
- 두가지 요청을 하나의 endpoint를 이용해 보낼 수 있음(endpoint 단일화)
(배열에 담긴 요청을 하나의 쿼리로 담아보냄)
오버페칭 (Over Fetchin
- 오버 페칭은 필요하지 않은 데이터까지 가져오는 것(Fetching)
- 응답 데이터 중 필요한 데이터만 골라서 받아오는 것이 가능
