809 VIEWS
핀터레스트 링크드인 LINE

JSON Web Signature라는 JSON에 서명하기위한 표준화는 IETF의 JOSE Working Group에서 시작되었습니다 [1].

초기 초안은

내 이름도 나왔는데, 이것은 OpenID Foundation의 AB / C Working Group에서 검토하고 있던 것을 IETF에 가져 왔기 때문입니다 [2].

@ ritou 님이 "OAuth 2.0 시대의 서명 요청은 무엇입니까?'라는 항목에서 언급했지만 Facebook의 signed_request 와 비슷합니다.

큰 차이는 signed_request

서명. 본문

형식이지만 JWS에서는

헤더 . 본문 . 서명

입니다. 이것에는 이유가 있습니다.

왜 "헤더. 본문. 서명 '?

세계의 패자, 페이스북과 같게 하면 좋지 않을까 하는 의견도 있을까는 생각합니다만, 이러한 형식이 된 데는, 현실적인 논리적인 이유가 있습니다.

헤더가 분리된 이유

signed_request 의 경우, 서명 파라미터를 본문에 포함해 버리고 있습니다. 본문을 암호화하고 싶다면이 접근법을 사용할 수 없습니다. 복호하기 위한 파라미터까지 암호화되어 버리기 때문입니다. 따라서, 헤더부에 이러한 암호 관련 파라미터를 분리해 둘 필요가 있습니다.

JWS는 JWE와 가능한 한 공통화되도록 노력하고 있습니다. 따라서 헤더를 분리해야했습니다.

서명이 마지막 부분에 있는 이유

외형상의 또 다른 큰 차이는 signed_request 그럼, 서명이 최초에 있는 것에 대해, JWS에서는 서명이 마지막에 있는 것입니다. 그러면, 자꾸자꾸 데이터를 송출해 버릴 수 있으므로, 모든 데이터를 버퍼할 필요가 없고, 서버 자원에 대해서 「친절한」으로부터입니다.

공통 특징

singed_request, JWS 공통의 특징도 있습니다.

  • 데이터 정규화는 수행하지 않음
  • 직렬화에는 base64url을 사용합니다.
  • 데이터 형식에는 JSON 사용
  • 모든 데이터에 서명할 수 있음

데이터 정규화는 수행하지 않음

XML Digital Signature 라는 표준이 있습니다.그러나, 다른 범용적이고 유연합니다.

직렬화에는 base64url 사용

base64가 아니라 base64url을 사용하는 이유는 종종 묻습니다. 없는 문자가 포함되어 있기 때문입니다.” JWS는 HTTP 헤더에 넣거나 GET이나 POST의 파라미터에 넣거나 합니다.

데이터 형식에는 JSON을 이용한다.

XML이 아닌 JSON을 이용하는 것은 JSON이 컴팩트하고 처리에 있어서의 성능도 쉽고, 무엇보다 개발자에게 인기가 있기 때문입니다.

모든 데이터에 서명할 수 있음

일단, JSON에 대한 서명의 방식이 되고 있습니다만, JSON의 파라미터의 하나에 base64url 인코딩한 데이터를 넣는 것만으로, 임의의 데이터에 서명 가능합니다.

누가 JWS를 사용합니까?

왜 이런 차이가 있는지는 알 수 있었다고 생각합니다.

우선, Facebook이 사용하지 않는다고 결정한 것은 아닙니다.그들은 현재의 signed_request 로 만족하고 있어 그 용도로 JWS를 사용할 필요를 느끼고 있지 않습니다만 다른 용도로는 이용할지도 모릅니다.

또한 페이스 북을 사용하지 않더라도 많은 플레이어가 사용할 것으로 예상됩니다.

언제 대응해야합니까?

JWS는 상대적으로 연도가 높다고 생각합니다. 실제로 Google이나 eBay 등은 구현하고 있습니다.

[1] 동시에 JSON Web Encryption이라는 암호화의 표준화도 시작되었습니다.

[2] OpenID Connect 등 Identity 표준에서 사용할 뿐만 아니라 범용적으로 사용할 수 있으므로 IETF로 표준화하기로 했습니다.

[3] 한편, JWE는 앞으로 약간의 수술에 걸릴 것입니다.