li 하위 code 태그에 폰트가 깨지는 문제가 있어서 마음이 아픕니다. 고쳐줘요 벨로퍼트님 ㅎㅎ
이번에는 사용자 인증 방식을 결정하자. SNS나 우리가 만드려는 서비스처럼 계정 개념이 들어가고, 리소스가 특정 사용자에게 귀속되는 서비스라면 인증이 꼭 필요하다.
HTTP는 연결 지향 프로토콜인 TCP 기반임에도 불구하고, 대표적인 비연결 지향 프로토콜이다. 따라서 한 번의 요청-응답 사이클이 완료되면 연결을 종료하기 때문에, 동일한 클라이언트가 요청을 아무리 많이 하더라도 프로토콜은 이를 모두 독립적인 요청으로 인지한다. 이 때문에 클라이언트는 매 HTTP 요청마다 본인이 누구인지를 인지시킬 수 있는 인증 정보(credential)를 요청의 어딘가에 포함시켜야 하며, 서버 또한 클라이언트의 자원 접근을 허용하기 전에 이러한 인증 정보를 기반으로 인증 과정을 일차적으로 거쳐야 한다. 사용자 A가 작성한 게시글을, 다른 사용자가 마음대로 수정/삭제할 수 없게 만들어야 하기 때문이다.
가장 먼저, 인증 정보를 HTTP 요청의 어디에서 관리할지를 결정하자.
Authorizaton 헤더를 선택하겠다. 그 이유는,
?
뒤에 붙는 query parameter는 고려해볼 만 하지만, 사용자 인증 하라고 Authorization 헤더가 표준화되어 있는데 굳이 query string을 써서 얻을 메리트가 없다.옛날에는 쿠키랑 세션을 이래저래 섞어서 썼던 기억이 있다. '자동 로그인'이라는 기능이 있어서, 이게 활성화되어 있으면 쿠키를 주고, 활성화되어 있지 않으면 세션을 줬다. 무슨 생각으로 그랬나 싶다. 코드
MDN의 Authorization 헤더 문서를 읽어 보자.
이제 사용자가 로그인을 했을 때, 서버는 그 사용자를 나타내는 특별한 값을 만들어서 전달해 권한을 부여하고, 사용자는 나중에 Authorization 헤더로 그 인증 데이터를 보내준다는 것까지 결정이 되었다. '사용자를 나타내는 값'을 어떻게 만들어낼 지는 표준이 결정해 줄 것이다. Authorization 헤더에는 값에 대한 표준도 있으니까.
Authorization 헤더의 value는 <type> <credentials>
처럼 생겨먹도록 하는 것이 표준이다. Bearer xmp98-cb35.potn6jz.zorj15gmb-
이 한가지 예다. 인증 타입에 따라 credential을 만들어내는 방식이 정해져 있기 때문에 맘대로 할 수 있는 부분이 아니다. 표준을 따르지 않더라도 이유는 있어야 한다. 그러니 인증 스키마에 대한 의사결정을 진행하자.
표준 상 Authorization 헤더의 값에는 RFC에 의해 표준화된 인증 스키마를 사용할 수 있게 되어 있다.
JWT을 사용하는 Bearer를 선택하겠다. 그 이유는,
그냥 아무 type이나 붙여서 값을 전달하거나, type 그거 명시해 봤자 딱히 쓸모 없는 것 같으니 type 안 붙여도 된다. DB 단에서 사용자와 매핑한 랜덤 문자열이나, 사용자 ID 자체가 인코딩된 문자열을 쓰는 등의 방식이다. 이번에 결정한 JWT도 그 연장선이다. 사실 경험 상 조직 내의 정책적으로 충분한 대안이 있다는 가정 하에, 인증에 관해서는 표준을 어겨도 그리 큰 문제는 없었던 것 같다.
JSON Web Token 소개 및 구조라는 글을 읽고 구글링 이리저리 하면서 JWT를 조금 알아두자.
결론은 표준을 어기는 것으로 결정이 났다. JWT가 충분한 대안이 되어서 의사결정의 후회가 없거나 적었으면 좋겠다. 물론 HTTPS 문제를 극복하고 나서 OAuth 기반으로 인증 시스템을 변경하는 것도 이 컨텐츠에 포함시킬 계획이다.
API 스펙 설계가 끝났으니 이제 프론트엔드 팀에게 전해줄 문서를 작성해야 한다. 이거야 뭐 대충 마크다운같은 걸로 열심히 시간 쏟아서 정리해도 되는 부분이지만, 더 나은 방법이 없을지부터 고민해 보자. 이번 챕터에서는 API 문서화 방식을 결정한다. 의사결정 API 문서화 방식 난 처음에 엑셀로 API를 문서화했다. 메소드 URI, 요청 ...
맨날 뭐 결정만 하느라 지쳤으니, 이제 드디어 조금이라도 생산적인 작업을 해보자. API 스펙 설계와 문서화 방식 결정인데, 우리가 여태까지 의사결정한 결과물들이 이 작업의 기반이 되어 도움을 줄 것이다. 여기로 다시 끌어와 보면, * HTTP API 설계 원칙을 기반으로 API 스펙을 디자인하기로 했다. * JSON을 직렬화 포맷으로 결정했다. ...
li 하위 code 태그에 폰트가 깨지는 문제가 있어서 마음이 아픕니다. 고쳐줘요 벨로퍼트님 ㅎㅎ 이번에는 사용자 인증 방식을 결정하자. SNS나 우리가 만드려는 서비스처럼 계정 개념이 들어가고, 리소스가 특정 사용자에게 귀속되는 서비스라면 인증이 꼭 필요하다. 도입 이유 사용자 인증 방식 HTTP는 연결 지향 프로토콜인 TCP 기반임에도...
이번엔 API 설계 원칙과 직렬화 포맷을 결정한다. 대부분의 경우 이 두가지는 '당연히 REST랑 JSON 아님?' 하며 관례적으로 결정하고 넘어가곤 하지만, 빼먹지 말고 이것도 의사결정 과정을 끼워 두자. 사실 이 앞에 프로토콜을 결정하는 챕터를 넣어두려 했는데, 거기까진 너무 TMI인 것 같아서 나중으로 미뤘다. 프로토콜은 일단 현재로선 일반적으로 사용...
이번엔 백엔드 포지션에서 어떤 방식으로 개발을 진행할지를 결정하자. 개발 프로세스 정립에 대해 두 가지의 의사결정을 진행할 것이다. 도입 이유 개발 프로세스 정립 개발 프로세스는 어떻게 이슈를 관리하고, 어떤 방식으로 작업을 진행하고, 완료된 작업은 어떤 과정을 거쳐서 실제 제품에 반영시킬지와 같은 것들을 규칙화시킨 것이다. 소프트웨어 공학...