refreshToken / graphQl

refreshToken

기존의 token은 탈취를 우려하여 일정시간을 정해놓으며 그 시간이 지나게 되면 만료되게 된다.

refreshToken을 토큰의 이 일정시간을 우리고 token을 사용하는 동안 자동으로 갱신되게 해서
토큰이 만료되지 않게 하는 방법이다.

기존엔 한개의 토큰만 만들었다면, 이제부터는 JWT1,JWT2를 만든다.
한개는 accessToken이고 다른 하나는 refreshToken이며
accessToken이고 은payload를 이용하며,
refreshToken이며 은 cookie의 httpOnly옵션을 통해서 받는다.
cookie의 httpOnly을 사용하게 되면 탈취를 방지하기 위해 JavaScript로 건드릴수 없게 되며
secure를 추가하여 https로 통신을 안전하게 할 수 있게 해준다.

• accessToken{
  payload
  }
• refreshToken{
  cookie
  httpOnly
  secure
  }

refreshToken은 토큰의 인가 가 필요한 동작을 할 경우
만료가 되었다면 브라우저에 UNAUTHENTICATED 라는 에러를 전송한다.

에러가 발생시 refreshTOken이 남아았다면, restoreAccessToken 기능을 이용해 JWT토큰을 새로만들어 브라우저에 전송한다.

이후 UNAUTHENTICATED 라는 에러가 작동했던 인가가 필요한 api를 재 호출하며,
그렇게 되면 이번엔 JWT 토큰이 존재하기에 토큰을 유지 할 수 있게 된다.

요약해보면
1. 토큰이 만료되면, onError(에러검증)을 통해 UNAUTHENTICATED를 검증하며
2. 에러가 브라우저에 전송될 경우 restoreAccessToken API를 통해 새로운 JWT토큰을 생성한다.
3. 새로생성한 JWT토큰으로 방금 에러를 전송한(실패한) API에 요청을 재시도 하며 정산적으로 동작하게 한다.

우리는 이런 과정을 Silent-AUTH 라고 하며 굉장히 빠른 시간동안 진행되기 때문에,
실제 사용자들을 이런과정을 실제로 인지하기 힘들고 그냥 로그인이된 상태로 기능으로 넘어가는 것 처럼 보이기 때문이다.

또한 인증을 하게되는 Token - login - logout - restoreAccessToken 까지의 과정을 AuthService라고하며,

인증이 아닌 인가가 필요한 기능을 가진 여러 API들을 ResourceService 라고한다.

AuthService와ResourceService는 또한 우리가 코딩을 하면서 기능들을 컴포넌트로 나누듯이 서로 비슷한 기능에 따라 한 서비스로 묶어 구조를 나누기도 하는데 우리는 이를 MicroService Architecture(MSA) 라 하며 잘게 쪼겐다는 의미를 가진다.

별개로 이런 인증부분을 OPen Api로 지원해주는 경우가 있는데 이것을 Open Authentication(Oauth)가 있는데
이를 우리는 보통 소셜로그인 이라하며 구글, 카카오, 네이버 등 다양한 기업에서 제공 되고 있다.

graphQl-restAPI

restAPI의 형태에선

조회(GET)
axios.get(API주소)
등록(POST)
axios.post(API주소, {데이터})

같은 형태로 조회/등록(요청)을 하였다.

하지만 나중에는

{
	createBoard(){
    ...data
    }
    fetchBoard(){
    ...fetch data
    }
}

같은 형태로 함수를 보내게 되었는데 이 방법이 grapgQl이다.

즉 graphQL은 rest-API의 POST방식이라는 소리이다.

가끔 graphQL이 요청에 실패해도 200번 성공코드가 나오는 경우가 있는데
이는 데이터전체를 POST하는 요청이 성공했단 의미의 200번인 셈이며 데이터 안쪽의

	createBoard(){
    ...data
    }
    fetchBoard(){
    ...fetch data
    }

data들이 성공 했다는 의미가 아닌셈이다.