먼저 설명을 보자면..
API에 접속하기 위해서는 access token을 API 서버에 제출해서 인증을 해야 합니다. 이 때 사용하는 인증 방법이 Bearer Authentication 입니다. 이 방법은 OAuth를 위해서 고안된 방법이고, RFC 6750에 표준명세서가 있습니다.
그리고 아래는 구글 디벨로퍼에서 가져온 문구다.
Bearer tokens in authorization headers are not sent by default.
한마디로 업계 표준인데 강제되어 있지 않고 개발자가 선택해서 잘 써야 한다. Jwt를 구현한 코드에서 클라이언트로부터 받은 토큰을 파싱하기 전에 먼저 앞 7글자, "Bearer "를 떼는 모습을 볼 수 있었다. 나는 별 생각 없이 마음대로 "Sieun sgksqksdg 어쩌구" 토큰 형식을 만들었는데 무식하면 용감하다. 나대지말고 업계 표준을 좀 지키자.
결국 Authorization 헤더를 <type> <credentials>
형식에 맞춘 value로 보내는 것을 선택했다. 헤더도 여러 종류가 있고 type도 선택할 수 있다. 인증 타입에 따라 credential을 만들어내는 방식이 정해져 있다고 한다.
아래는 현재 내 클라이언트에서 헤더에 토큰을 보내는 코드다.
axios.get("http://localhost:8080/onlynormal", {
headers: {
"Authorization" : "Bearer "+ this.state.token
}
})
JWT을 사용하는 Bearer를 선택하겠다. 그 이유는,
그냥 아무 type이나 붙여서 값을 전달하거나, type 그거 명시해 봤자 딱히 쓸모 없는 것 같으니 type 안 붙여도 된다. DB 단에서 사용자와 매핑한 랜덤 문자열이나, 사용자 ID 자체가 인코딩된 문자열을 쓰는 등의 방식이다. 이번에 결정한 JWT도 그 연장선이다. 사실 경험 상 조직 내의 정책적으로 충분한 대안이 있다는 가정 하에, 인증에 관해서는 표준을 어겨도 그리 큰 문제는 없었던 것 같다.
출처:
백엔드가 이정도는 해줘야 함 - 5. 사용자 인증 방식 결정
refresh-token
과 access-token
을 함께 보낸다. access-token
을 까서 필요한 정보(username)를 얻고 여기서는 expiry date를 무시한다.refresh-token
과 db의 최신 refresh-token
를 비교하는데 다르면 불허한다.access-token
에 있던 데이터로 새로운 토큰을 만들어 전송한다. 새로 쓰고 싶으면 db 접근 하든지4번에 대해 어떤 외국 사이트의 개발자는
면서 무조건 후자를 주장했다. 내 경우 일단 username만 보낼거기 때문에 재사용해도 상관없다고 판단했지만 나도 굳이 같이 보내야 하는 이유가 없다고 생각해서 refresh만 보낼 것이다.
-> 1/20 변경사항: 같이 안보내면 결국 refresh token 자체가 key가 되거나 뭔가 db에서 또 확인을 해봐야할텐데 그냥 파싱 한번 더 해도 될듯. Username같은 고유한 값 정도는 가지고 와서 그걸로 db에 접근하더라도
JWT의 구체적인 구현 방법에 대해서는 아주 이거다 싶게 정해진 정석은 없는것 같다. Access token이나 Refresh token 의 만료 기간이라든가, refresh할때 access token을 같이 보낼 것인지 정보를 재사용할것인지, refresh token의 payload에 무엇을 담아야 하는지.. 등등.
그리고 그 컨셉 자체가 참신해서 그렇지 구현하기에는 정말 별거없는 친구구나 라는걸 느낀다...너무 별게 없어서 오히려 정해진게 너무 없는 느낌이다. 검색해보면 다른 사람들도 다 그런다 사람은 다 똑같아..
정리가 잘 되었네요.
도움이 많이 되었습니다.