DECLARE @info NVARCHAR(100)='{"name":"John","skills":["C#","SQL"]}'
PRINT @info
-- Update name
SET @info=JSON_MODIFY(@info,'$.name','Mike')
PRINT @info
-- Insert surname
SET @info=JSON_MODIFY(@info,'$.surname','Smith')
PRINT @info
-- Set name NULL
SET @info=JSON_MODIFY(@info,'strict $.name',NULL)
PRINT @info
-- Delete name
SET @info=JSON_MODIFY(@info,'$.name',NULL)
PRINT @info
-- Add skill
SET @info=JSON_MODIFY(@info,'append $.skills','Azure')
PRINT @info
JWT(Json Web Token)은 위와 같은 일련의 과정 속에서 나타난 하나의 인터넷 표준 인증 방식입니다. 말 그대로 인증에 필요한 정보들을 Token에 담아 암호화시켜 사용하는 토큰인 것이죠.
JWT는 리소스에 대한 액세스 권한을 부여할 수 있는 자격 증명입니다. 붙여넣는 위치에 주의하세요! 우리는 토큰을 기록하지 않으며 모든 유효성 검사 및 디버깅은 클라이언트 측에서 수행됩니다.
JSON 웹 토큰이란 무엇입니까?
JWT(JSON Web Token)는 당사자 간에 정보를 JSON 개체로 안전하게 전송하기 위한 간결하고 자체 포함된 방법을 정의하는개방형 표준(RFC 7519 )입니다.이 정보는 디지털 서명되어 있으므로 확인하고 신뢰할 수 있습니다.JWT는 비밀( HMAC 알고리즘 사용)을 사용하거나RSA또는ECDSA를 사용하는 공개/개인 키 쌍을 사용하여서명할 수 있습니다.
JWT를 암호화하여 당사자 간의 비밀도 제공할 수 있지만 서명된 토큰에 중점을 둘 것입니다 .서명된 토큰은 그 안에 포함된 클레임의 무결성을 확인할 수 있는반면 암호화된 토큰은 이러한 클레임을 다른 당사자로부터숨길 수 있습니다.공개/개인 키 쌍을 사용하여 토큰에 서명할 때 서명은 개인 키를 보유하고 있는 당사자만 서명했음을 증명합니다.
JSON 웹 토큰은 언제 사용해야 합니까?
다음은 JSON 웹 토큰이 유용한 몇 가지 시나리오입니다.
권한 부여: JWT를 사용하는 가장 일반적인 시나리오입니다.사용자가 로그인하면 각 후속 요청에 JWT가 포함되어 사용자가 해당 토큰으로 허용되는 경로, 서비스 및 리소스에 액세스할 수 있습니다.싱글 사인온은 오버헤드가 적고 여러 도메인에서 쉽게 사용할 수 있기 때문에 오늘날 JWT를 널리 사용하는 기능입니다.
정보 교환: JSON 웹 토큰은 당사자 간에 정보를 안전하게 전송하는 좋은 방법입니다.예를 들어 공개/개인 키 쌍을 사용하여 JWT에 서명할 수 있기 때문에 발신자가 누구인지 확인할 수 있습니다.또한 헤더와 페이로드를 사용하여 서명을 계산하므로 콘텐츠가 변조되지 않았는지 확인할 수도 있습니다.
JSON 웹 토큰 구조는 무엇입니까?
간결한 형태의 JSON 웹 토큰은 점(.)으로 구분된 세 부분으로 구성되며 다음과 같습니다.
헤더
유효 탑재량
서명
따라서 JWT는 일반적으로 다음과 같습니다.
xxxxx.yyyyy.zzzzz
다른 부분을 분해해 봅시다.
헤더
헤더는 일반적으로JWT인 토큰 유형과 HMAC SHA256 또는 RSA와 같이 사용 중인 서명 알고리즘의 두 부분으로 구성됩니다.
예를 들어:
{
"alg": "HS256",
"typ": "JWT"
}
그런 다음 이 JSON은JWT의 첫 번째 부분을 형성하도록 인코딩된Base64Url 입니다.
유효 탑재량
토큰의 두 번째 부분은 클레임을 포함하는 페이로드입니다.클레임은 엔터티(일반적으로 사용자) 및 추가 데이터에 대한 설명입니다.클레임에는 등록,공개및비공개클레임 의 세 가지 유형이 있습니다.
등록된 클레임: 필수는 아니지만 유용하고 상호 운용 가능한 클레임 집합을 제공하기 위해 권장되는 미리 정의된 클레임 집합입니다.그 중 일부는iss(발급자),exp(만료 시간),sub(제목),aud(대상) 및기타입니다.
사용자가 보호된 경로 또는 리소스에 액세스하려고 할 때마다 사용자 에이전트는 일반적으로Bearer스키마 를 사용하여Authorization헤더 에서 JWT를 보내야 합니다.헤더의 내용은 다음과 같아야 합니다.
Authorization: Bearer <token>
이는 특정 경우에 상태 비저장 권한 부여 메커니즘이 될 수 있습니다.서버의 보호 경로는Authorization헤더에 유효한 JWT가 있는지 확인하고 JWT가 있는 경우 사용자는 보호된 리소스에 액세스할 수 있습니다.JWT에 필요한 데이터가 포함되어 있으면 특정 작업에 대해 데이터베이스를 쿼리해야 할 필요성이 줄어들 수 있지만 항상 그런 것은 아닙니다.
토큰이Authorization헤더로 전송되면 CORS(Cross-Origin Resource Sharing)는 쿠키를 사용하지 않으므로 문제가 되지 않습니다.
다음 다이어그램은 JWT를 얻고 API 또는 리소스에 액세스하는 데 사용하는 방법을 보여줍니다.
애플리케이션 또는 클라이언트가 권한 부여 서버에 권한 부여를 요청합니다.이것은 다른 권한 부여 흐름 중 하나를 통해 수행됩니다.예를 들어, 일반적인OpenID Connect호환 웹 애플리케이션은인증 코드 흐름/oauth/authorize을 사용하여 엔드포인트를 통과합니다.
권한이 부여되면 권한 서버는 애플리케이션에 액세스 토큰을 반환합니다.
애플리케이션은 액세스 토큰을 사용하여 보호된 리소스(예: API)에 액세스합니다.
서명된 토큰을 사용하면 토큰에 포함된 모든 정보가 변경할 수 없는 경우에도 사용자 또는 다른 당사자에게 노출됩니다.즉, 토큰 안에 비밀 정보를 넣으면 안 됩니다.
JSON 웹 토큰을 사용해야 하는 이유는 무엇입니까?
SWT(Simple Web Tokens)및SAML(Security Assertion Markup Language Tokens)과 비교할 때JSON 웹 토큰(JWT)의 이점에 대해 이야기해 보겠습니다.
JSON은 XML보다 덜 장황하기 때문에 인코딩될 때 크기도 작아져 JWT가 SAML보다 더 간결해집니다.따라서 JWT는 HTML 및 HTTP 환경에서 전달하기에 좋은 선택입니다.
보안 측면에서 SWT는 HMAC 알고리즘을 사용하는 공유 비밀로만 대칭적으로 서명할 수 있습니다.그러나 JWT 및 SAML 토큰은 서명을 위해 X.509 인증서 형식의 공개/개인 키 쌍을 사용할 수 있습니다.모호한 보안 허점을 도입하지 않고 XML 디지털 서명으로 XML에 서명하는 것은 JSON 서명의 단순성과 비교할 때 매우 어렵습니다.
JSON 파서는 객체에 직접 매핑되기 때문에 대부분의 프로그래밍 언어에서 일반적입니다.반대로 XML에는 자연스러운 문서 대 개체 매핑이 없습니다.이렇게 하면 SAML 어설션보다 JWT로 작업하기가 더 쉽습니다.
사용에 관해서는 JWT가 인터넷 규모로 사용됩니다.이는 여러 플랫폼, 특히 모바일에서 JSON 웹 토큰의 클라이언트 측 처리 용이성을 강조합니다.
-- update select 로 json data 변경하기
UPDATE AA SET
AA.컬럼1 = JSON_MODIFY(BB.컬럼1,'$.must.title_inner',JSON_VALUE(BB.컬럼1, '$.must.title'))
from Table01 AS AA, Table01 AS BB
where BB.key = AA.KEY
자바 스크립트는 서로 다른 도메인에 대한 요청을 보안상 제한합니다. 이 정책을 동일근원정책(Same-Origin Policy, SOP) 정책이라고 하며, 이러한 정책으로 인해 생기는 이슈를 cross-domain 문제라고 합니다. 개발을 하다보면 어쩔 수 없이 다른 도메인으로부터 데이터를 가져와야 하는 경우가 많기에 많은 사람들이 cross-domain 이슈를 겪고 있습니다.
이런 경우 사용할 수 있는 것이 JSONP(JSON with Padding)입니다. 처음 JSONP를 접했을 때 잘 정리가 되지 않았던, 사용할 때 명확히 알아야 할 것들을 정리해보았습니다.
SQL Server 및 SQL Database에서 JSON은 기본 제공 데이터 형식이 아니며 SQL Server에는 사용자 지정 JSON 인덱스가 없습니다.그러나 표준 인덱스를 사용하여 JSON 문서에 대한 쿼리를 최적화할 수 있습니다.
데이터베이스 인덱스는 필터 및 정렬 작업의 성능을 향상합니다.인덱스를 사용하지 않으면 SQL Server는 데이터를 쿼리할 때마다 전체 테이블을 검색해야 합니다.
계산된 열을 사용하여 JSON 속성 인덱싱
SQL Server에 JSON 데이터를 저장하는 경우 JSON 문서속성하나 이상을 기준으로 쿼리 결과를 필터링하거나 정렬하는 것이 일반적입니다.
예제
이 예제에서는 AdventureWorksSalesOrderHeader테이블에 판매 주문에 대한 다양한 정보가 JSON 형식으로 포함되어 있는Info열이 있다고 가정합니다.예를 들어 이 열은 고객, 영업 사원, 배송 및 대금 청구 주소 등에 대한 정보를 포함합니다.Info열의 값을 사용하여 고객의 판매 주문을 필터링하려고 합니다.
최적화할 쿼리
다음은 인덱스를 사용하여 최적화할 쿼리 형식의 예제입니다.
SQL복사
SELECT SalesOrderNumber, OrderDate, JSON_VALUE(Info, '$.Customer.Name') AS CustomerName FROM Sales.SalesOrderHeader WHERE JSON_VALUE(Info, '$.Customer.Name') = N'Aaron Campbell'
예제 인덱스
JSON 문서에서 속성에 대한ORDER BY절 또는 필터링의 속도를 향상하려면 다른 열에서 이미 사용 중인 동일한 인덱스를 사용할 수 있습니다.그러나 JSON 문서에서는 속성을직접참조할 수 없습니다.
먼저 필터링에 사용할 값을 반환하는 “가상 열”을 만들어야 합니다.
그런 다음 해당 가상 열에 인덱스를 만들어야 합니다.
다음 예제에서는 인덱싱에 사용할 수 있는 계산 열을 만듭니다.그런 다음 새 계산 열에서 인덱스를 만듭니다.이 예제에서는 JSON 데이터의$.Customer.Name경로에 저장된 고객 이름을 표시하는 열을 만듭니다.
SQL복사
ALTERTABLE Sales.SalesOrderHeader ADD vCustomerName AS JSON_VALUE(Info,'$.Customer.Name') CREATEINDEX idx_soh_json_CustomerName ON Sales.SalesOrderHeader(vCustomerName)
계산 열에 대한 자세한 정보
계산 열은 지속형이 아닙니다.인덱스를 다시 작성해야 하는 경우에만 계산됩니다.테이블에서 추가 공간을 차지하지 않습니다.
쿼리에서 사용할 동일한 식으로 계산 열을 만드는 것이 중요합니다. 이 예제의 식은JSON_VALUE(Info, '$.Customer.Name')입니다.
쿼리를 다시 작성할 필요가 없습니다.위 예제 쿼리와 같이JSON_VALUE함수가 포함된 식을 사용하는 경우 SQL Server는 같은 식을 사용하는 동일한 계산 열이 있는지 확인한 후 해당하는 경우 인덱스를 적용합니다.
이 예제에 대한 실행 계획
다음은 이 예제의 쿼리 실행 계획입니다.
SQL Server는 전체 테이블을 검색하지 않고 비클러스터형 인덱스에서 인덱스 검색하여 지정된 조건을 충족하는 행을 찾습니다.그런 다음SalesOrderHeader테이블에서 키 조회를 사용하여 쿼리에서 참조된 다른 열(이 예제에서는SalesOrderNumber및OrderDate)을 가져옵니다.
포괄 열을 사용하여 추가로 인덱스 최적화
인덱스에 필요한 열을 추가하는 경우 테이블에서 이러한 조회를 추가로 수행할 필요가 없습니다.위의CREATE INDEX예제를 확장하는 다음 예제처럼 이러한 열을 표준형 포괄 열로 추가할 수 있습니다.
SQL복사
CREATEINDEX idx_soh_json_CustomerName ON Sales.SalesOrderHeader(vCustomerName) INCLUDE(SalesOrderNumber,OrderDate)
이 경우 비클러스터형 JSON 인덱스에 필요한 모든 사항이 있기 때문에 SQL Server는SalesOrderHeader테이블에서 데이터를 추가로 읽을 필요가 없습니다.이러한 인덱스 유형은 쿼리에서 JSON과 열 데이터를 결합하고 작업에 대한 최적의 인덱스를 생성하기 위한 좋은 방법입니다.
JSON 인덱스는 데이터 정렬 인식 인덱스입니다.
JSON 데이터에 대한 중요한 인덱스 기능은 인덱스의 데이터 정렬 인식 기능입니다.계산 열을 만들 때 사용하는JSON_VALUE함수의 결과는 입력 식에서 데이터 정렬을 상속하는 텍스트 값입니다.따라서 인덱스의 값은 원본 열에 정의된 데이터 정렬 규칙을 사용하여 정렬됩니다.
인덱스가 데이터 정렬을 인식한다는 것을 보여주기 위해 다음 예제에서는 기본 키와 JSON 콘텐츠가 있는 단순한 컬렉션 테이블을 만듭니다.
SQL복사
CREATETABLE JsonCollection ( idINTIDENTITYCONSTRAINT PK_JSON_ID PRIMARY KEY, jsonNVARCHAR(MAX) COLLATE SERBIAN_CYRILLIC_100_CI_AI CONSTRAINT [Content should be formatted asJSON] CHECK(ISJSON(json)>0) )
이전 명령은 JSON 열에 대하여 세르비아어 키릴 자모 데이터 정렬을 지정합니다.다음 예제에서는 테이블을 자동으로 채우고 이름 속성에 대한 인덱스를 만듭니다.
앞의 명령은 JSON$.name속성의 값을 나타내는 계산 열vName에 표준 인덱스를 만듭니다.세르비아어-키릴 자모 코드 페이지에서 문자 순서는 'А', 'Б', 'В', 'Г', 'Д', 'Ђ', 'Е' 등의 순서입니다.JSON_VALUE함수의 결과는 원본 열에서 데이터 정렬을 상속하므로 인덱스에서 항목의 순서는 세르비아어 키릴 자모 규칙을 따릅니다.다음 예제에서는 이 컬렉션을 쿼리하고 이름을 기준으로 결과를 정렬합니다.
SQL복사
SELECT JSON_VALUE(json,'$.name'),* FROM JsonCollection ORDERBY JSON_VALUE(json,'$.name')
실제 실행 계획을 보면 비클러스터형 인덱스에서 정렬된 값을 사용함을 확인할 수 있습니다.
쿼리에ORDER BY절이 있지만 실행 계획은 Sort 연산자를 사용하지 않습니다.JSON 인덱스는 이미 세르비아어 키릴 자모 규칙에 따라 정렬됩니다.따라서 SQL Server는 결과가 이미 정렬된 비클러스터형 인덱스를 사용합니다.
그러나ORDER BY식의 데이터 정렬을 변경하면(예:JSON_VALUE함수 뒤에COLLATE French_100_CI_AS_SC추가) 다른 쿼리 실행 계획이 제공됩니다.
인덱스 값 순서는 프랑스어 데이터 정렬 규칙을 따르지 않으므로 SQL Server는 정렬 결과에 대한 인덱스를 사용할 수 없습니다.따라서 프랑스어 데이터 정렬 규칙을 사용하여 결과를 정렬하는 정렬 연산자를 추가합니다.