17 ਅਕਤੂ 2025·7 ਮਿੰਟ
JWT ਕੀ ਹੈ? JSON Web Tokens ਲਈ ਸਪੱਸ਼ਟ ਗਾਈਡ
ਜਾਣੋ JWT (JSON Web Token) ਕੀ ਹੈ, ਇਸਦੇ ਤਿੰਨ ਹਿੱਸੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਹ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਆਮ ਟੋਕਨ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਮੁੱਖ ਸੁਰੱਖਿਆ ਸੁਝਾਅ।
ਜਾਣੋ JWT (JSON Web Token) ਕੀ ਹੈ, ਇਸਦੇ ਤਿੰਨ ਹਿੱਸੇ ਕਿਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਇਹ ਕਿੱਥੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਆਮ ਟੋਕਨ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣ ਲਈ ਮੁੱਖ ਸੁਰੱਖਿਆ ਸੁਝਾਅ।
A JWT (JSON Web Token) ਇੱਕ ਕੰਪੈਕਟ, URL-ਸੇਫ਼ ਸਤਰ ਹੈ ਜੋ ਇੱਕ ਵਰਤੋਂਕਾਰ ਜਾਂ ਸੈਸ਼ਨ ਬਾਰੇ ਤੱਥ (ਆਮ ਤੌਰ 'ਤੇ) ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮਾਂ ਦਰਮਿਆਨ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਕਸਰ ਇਹ ਇੱਕ ਲੰਮਾ ਮੁੱਲ ਹੁੰਦਾ ਹੈ ਜੋ eyJ... ਵਰਗੇ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ HTTP ਹੈਡਰ ਵਿੱਚ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ Authorization: Bearer \u003ctoken\u003e.
ਪੰਰਪਰਾ अनुसार ਲੌਗਿਨਸ ਅਕਸਰ ਸਰਵਰ ਸੈਸ਼ਨ ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਤੁਹਾਡੇ ਸਾਇਨ-ਇਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ ਸੈਸ਼ਨ ਡੇਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਇਕ ਸੈਸ਼ਨ ID ਕੁਕੀ ਦਿੰਦਾ ਹੈ। ਹਰ ਰਿਕਵੇਸਟ ਉਹ ਕੁਕੀ ਸ਼ਾਮਿਲ ਕਰਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਸੈਸ਼ਨ ਨੂੰ ਲੁੱਕਅੱਪ ਕਰਦਾ ਹੈ।
ਟੋਕਨ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਨਾਲ, ਸਰਵਰ ਹਰ ਯੂਜ਼ਰ ਰਿਕਵੇਸਟ ਲਈ ਸਟੇਟ ਰੱਖਣ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ। ਇਸਦੀ ਥਾਂ, ਕਲਾਇੰਟ ਇੱਕ ਟੋਕਨ (ਜਿਵੇਂ JWT) ਰੱਖਦਾ ਹੈ ਅਤੇ API ਕਾਲਾਂ ਨਾਲ ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ। ਇਹ APIs ਲਈ ਲੋਕਪ੍ਰਿਯ ਹੈ ਕਿਉਂਕਿ ਇਹ:
ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਨੁਆਨਸ: “stateless” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਕਦੇ ਵੀ ਸਰਵਰ-ਪਾਸੇ ਜਾਂਚ ਨਹੀਂ।” ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਸਿਸਟਮ ਟੋਕਨਾਂ ਨੂੰ ਯੂਜ਼ਰ ਸਥਿਤੀ, ਕੀ ਰੋਟੇਸ਼ਨ, ਜਾਂ ਰਿਵੋਕੇਸ਼ਨ ਮਕੈਨਿਜ਼ਮਾਂ ਵੱਲੋਂ ਵੀ ਵੈਰੀਫਾਈ ਕਰਦੇ ਹਨ।
JWT ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਸਬੂਤ (ਤੁਸੀਂ ਸਾਈਂ-ਇਨ ਹੋ) ਅਤੇ ਮੂਲ ਅਧਿਕਾਰ ਸੰਕੇਤ (ਰੋਲ, ਅਧਿਕਾਰ, ਸਕੋਪ) ਰੱਖਦੇ ਹਨ—ਪਰ ਸਰਵਰ ਨੂੰ ਫਿਰ ਵੀ ਅਧਿਕਾਰ ਨਿਯਮ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ JWTs ਨੂੰ ਐਕਸੈਸ ਟੋਕਨ ਵਜੋਂ ਵੇਖੋਗੇ:
ਇੱਕ JWT ਇੱਕ ਕੰਪੈਕਟ ਸਤਰ ਹੈ ਜੋ ਤਿੰਨ ਭਾਗਾਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਹਰ ਇੱਕ base64url-ਇਨਕੋਡ ਅਤੇ ਡੌਟ ਨਾਲ ਵੱਖਰੇ:
header.payload.signature
ਉਦਾਹਰਨ (ਸੰਖਿਪਤ):
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…
Header ਦੱਸਦਾ ਹੈ ਕਿ ਟੋਕਨ ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ—ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਸਾਈਨਿੰਗ ਅਲਗੋਰਿਦਮ ਹੈ (ਉਦਾਹਰਨ HS256, RS256/ES256) ਅਤੇ ਟੋਕਨ ਦੀ ਕਿਸਮ।
ਆਮ ਖੇਤਰ:
typ: ਅਕਸਰ "JWT" (ਅਮਲ ਵਿੱਚ ਅਕਸਰ ਨਜ਼ਰਅੰਦਾਜ਼)alg: ਵਰਤੀ ਗਈ ਸਾਈਨਿੰਗ ਅਲਗੋਰਿਦਮkid: ਕੀ ਆਈਡੈਂਟੀਫਾਇਰ ਜੋ ਰੋਟੇਸ਼ਨ ਦੌਰਾਨ ਵੈਰੀਫਾਇਰ ਨੂੰ ਸਹੀ ਕੀ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈਸੁਰੱਖਿਆ ਨੋਟ: ਹੈਡਰ 'ਤੇ ਅੰਨ੍ਹੇ ਰੂਪ ਵਿੱਚ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਉਹ ਅਲਗੋਰਿਦਮ ਜੋ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ ਉਹਨਾਂ ਦੀ allowlist ਲਗਾਓ ਅਤੇ alg: "none" ਨੂੰ ਕਦੇ ਵੀ ਸਵੀਕਾਰ ਨਾ ਕਰੋ।
ਪੇਲੋਡ ਉਨ੍ਹਾਂ "claims" (ਫ਼ੀਲਡ) ਨੂੰ ਰੱਖਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਤੇ ਟੋਕਨ ਸੰਦਰਭ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਿੰਦੇ ਹਨ: ਟੋਕਨ ਕਿਸ ਲਈ ਹੈ, ਕਿਸਨੇ ਜਾਰੀ ਕੀਤਾ, ਅਤੇ ਕਦੋਂ ਇਹ ਖਤਮ ਹੋ ਜਾਵੇਗਾ।
ਮਹੱਤਵਪੂਰਨ: JWT ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਨਕ੍ਰਿਪਟਡ ਨਹੀਂ ਹੁੰਦੇ। Base64url ਇੰਕੋਡਿੰਗ ਟੋਕਨ ਨੂੰ URL-ਸੇਫ਼ ਬਣਾਉਂਦੀ ਹੈ; ਇਹ ਡੇਟਾ ਨੂੰ ਛੁਪਾਉਂਦੀ ਨਹੀਂ।
ਇਸ ਲਈ ਰਾਫ਼ਤਾਂ (passwords, API keys) ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿੱਜੀ ਡੇਟਾ JWT ਵਿੱਚ ਨਹੀਂ ਰੱਖਣੀ ਚਾਹੀਦੀ।
Signature ਹੈਡਰ + ਪੇਲੋਡ ਨੂੰ ਇੱਕ ਕੀ ਨਾਲ ਸਾਈਨ ਕਰਕੇ ਬਣਦੀ ਹੈ:
ਸਿਗਨੇਚਰ ਇੰਟੀਗ੍ਰਿਟੀ ਦਿੰਦੀ ਹੈ: ਇਹ ਸਰਵਰ ਨੂੰ ਯਕੀਨ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਟੋਕਨ ਤਬਦੀਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸਾਈਨਰ ਨੇ ਬਣਾਇਆ। ਇਹ ਗੁਪਤਤਾ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ।
ਕਿਉਂਕਿ JWT ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਹੈਡਰ ਅਤੇ ਪੇਲੋਡ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ, ਵੱਡੇ ਟੋਕਨ ਬੈਂਡਵਿਡਥ ਅਤੇ ਓਵਰਹੈਡ ਵਧਾਉਂਦੇ ਹਨ। claims ਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ ਅਤੇ ਭਾਰੀ ਡੇਟਾ ਦੀ ਥਾਂ ਸਿਰਫ਼ ਸੂਚਕ (ID) ਰੱਖੋ।
Claims ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਕਿਸਮਾਂ ਵਿੱਚ ਹੋਂਦੀਆਂ ਹਨ: registered (ਸਟੈਂਡਰਡ ਨਾਮ) ਅਤੇ custom (ਆਪ ਦੀ ਐਪ ਦੇ ਖੇਤਰ)।
iss (issuer): ਟੋਕਨ ਕਿਸਨੇ ਬਣਾਇਆsub (subject): ਟੋਕਨ ਕਿਸ ਬਾਰੇ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ ID)aud (audience): ਟੋਕਨ ਕਿਸ ਲਈ ਹੈ (ਉਦਾਹਰਨ ਲਈ ਕੋਈ ਨਿਰਧਾਰਿਤ API)exp (expiration time): ਕਦੋਂ ਟੋਕਨ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇiat (issued at): ਟੋਕਨ ਕਦੋਂ ਬਣਿਆnbf (not before): ਇਸ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਟੋਕਨ ਸਵੀਕਾਰ ਨਾ ਕੀਤਾ ਜਾਵੇਸਿਰਫ਼ ਉਹੀ ਡੇਟਾ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਨੂੰ ਅਥੇਨ/ਅਧਿਕਾਰ ਫੈਸਲਾ ਕਰਨ ਲਈ ਸਚਮੁਚ ਚਾਹੀਦਾ ਹੈ।
ਚੰਗੇ ਉਦਾਹਰਨ:
user_id)ਵਹੀ-ਹੀ claims ਜੋ ਬਹੁਤ ਸਾਰਾ ਪ੍ਰੋਫ਼ਾਈਲ ਡੇਟਾ ਨਕਲ ਕਰਦੇ ਹਨ ਉਹ ਬਹੁਤ ਸਤੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਟੋਕਨ ਨੂੰ ਸੁਸਤੀ ਕਰਦੇ ਹਨ ਅਤੇ ਲੀਕ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਵੱਧਦੇ ਹਨ।
ਕਿਉਂਕਿ ਪੇਲੋਡ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਕਦੇ ਵੀ ਨਾ ਰੱਖੋ:
ਜੇ ਤੁਹਾਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਹਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਸਟੋਰ ਕਰੋ ਅਤੇ ਟੋਕਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਰੇਫਰੈਂਸ (ਜਿਵੇਂ ID) ਰੱਖੋ—ਯਾ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇੰਕ੍ਰਿਪਟਡ ਟੋਕਨ ਫਾਰਮੈਟ (JWE) ਵਰਤੋ।
ਸਾਈਨਿੰਗ ਇੰਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਹੈ।
ਜਦੋ JWT ਜਾਰੀ ਹੁੰਦਾ ਹੈ, ਸਰਵਰ ਹੈਡਰ + ਪੇਲੋਡ ਨੂੰ ਸਾਈਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਟੋਕਨ ਬਾਅਦ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਰਵਰ ਸਿਗਨੇਚਰ ਨੂੰ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਨੇ ਇਕ حرف ਵੀ ਬਦਲਿਆ (ਉਦਾਹਰਣ: "role":"user" ਤੋਂ "role":"admin"), ਵੈਰੀਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਟੋਕਨ ਰੱਦ ਕੀਤਾ ਜਾਵੇਗਾ।
JWT ਇੱਕ ਟੋਕਨ ਫਾਰਮੈਟ ਹੈ। OAuth 2.0 ਅਤੇ OpenID Connect (OIDC) ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਹਨ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਐਪਸ ਟੋਕਨ ਕਿਵੇਂ ਬੇਨਤੀ, ਜਾਰੀ ਅਤੇ ਵਰਤਦੇ ਹਨ।
OAuth 2.0 ਮੁੱਖ ਤੌਰ 'ਤੇ ਅਧਿਕਾਰ ਬਾਰੇ ਹੈ: ਇੱਕ ਐਪ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਪਾਸਵਰਡ ਸਾਂਝੀ ਕੀਤੇ ਬਗੈਰ API ਤੱਕ ਪਹੁੰਚ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ।
ਐਕਸੈਸ ਟੋਕਨ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਹੁੰਦੇ ਹਨ (ਕਈ ਮਿੰਟ). ਛੋਟੀ ਮਿਆਦ ਟੋਕਨ ਲੀਕ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਘੱਟ ਕਰਦੀ ਹੈ।
OIDC OAuth 2.0 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਜੋੜਦਾ ਹੈ ਅਤੇ ਇੱਕ ID token ਲਿਆਉਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ JWT ਹੁੰਦਾ ਹੈ।
ਇੱਕ ਮੁੱਖ ਨਿਯਮ: ID token ਨੂੰ API ਕਾਲ ਕਰਨ ਲਈ ਵਰਤੋ ਨਾ।
ਜੇ ਤੁਸੀਂ ਪ੍ਰੈਕਟਿਕਲ ਫਲੋਜ਼ ਬਾਰੇ ਹੋਰ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog/jwt-authentication-flow ਵੇਖੋ।
ਇੱਕ ਆਮ ਫਲੋ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
ਯੂਜ਼ਰ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ (email/password, SSO ਆਦਿ)। ਜੇ ਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਇੱਕ JWT (ਅਕਸਰ access token) ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਮੈਜਰ ਕਲੇਮਾਂ ਜਿਵੇਂ subject ਅਤੇ expiration ਹੁੰਦੇ ਹਨ।
ਸਰਵਰ ਟੋਕਨ ਨੂੰ ਸਾਈਨ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਲਾਇੰਟ (ਵੈੱਬ ਐਪ, ਮੋਬਾਈਲ ਐਪ, ਜਾਂ ਹੋਰ ਸੇਵਾ) ਨੂੰ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।
ਸੁਰੱਖਿਅਤ ਏਂਡਪੋਇੰਟਾਂ ਲਈ, ਕਲਾਇੰਟ JWT ਨੂੰ Authorization ਹੈਡਰ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:
Authorization: Bearer \u003cJWT\u003e
ਰਿਕਵੇਸਟ ਸਰਵ ਕੀਤਾ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, API ਆਮ ਤੌਰ 'ਤੇ ਜਾਂਚਦਾ ਹੈ:
exp (ਮਿਆਦ ਖਤਮ ਨਹੀਂ ਹੋਈ)iss (ਉਮੀਦ ਕੀਤਾ ਗਿਆ issuer)aud (ਇਹ API ਲਈ ਹੈ)ਜੇ ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਪਾਸ ਹੋਦੀਆਂ ਹਨ, API ਯੂਜ਼ਰ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਮੰਨਦਾ ਹੈ ਅਤੇ ਅਧਿਕਾਰ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: ਰਿਕਾਰਡ-ਲੇਵਲ ਅਧਿਕਾਰ)।
ਕਿਉਂਕਿ ਸਿਸਟਮ ਘੜੀਆਂ ਥੋੜ੍ਹੀ ਘੁੱਟ-ਫੜ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਬਹੁਤ ਸਾਰੀਆਂ ਸਿਸਟਮ ਟਾਈਮ-ਅਧਾਰਿਤ claims ਜਿਵੇਂ exp ਅਤੇ nbf ਦੀ ਜਾਂਚ ਸਮੇਂ ਛੋਟਾ clock skew ਲਗਾਉਂਦੇ ਹਨ। ਸਕਿਊਅ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਟੋਕਨ ਦੀ ਮਿਆਦ ਜ਼ਿਆਦਾ ਨਾ ਵਧੇ।
ਸਟੋਰੇਜ ਦੇ ਚੋਣ ਇਹ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਹਮਲਾਵਰ ਕਿਸ ਤਰ੍ਹਾਂ ਟੋਕਨ ਚੁਰਾ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿਸ ਹੱਦ ਤੱਕ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦਾ ਹੈ।
In-memory ਸਟੋਰੇਜ (SPA ਲਈ ਅਕਸਰ ਸਿਫਾਰਸ਼ੀ) access token ਨੂੰ JS ਸਟੇਟ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਇਹ ਰਿਫ੍ਰੈਸ਼ 'ਤੇ ਕਲੀਅਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਾਦ ਵਿੱਚ ਚੋਰੀ ਹੋਣ ਦਾ ਖਤਰਾ ਘੱਟ ਕਰਦਾ ਹੈ, ਪਰ XSS ਬੱਗ ਦੌਰਾਨ ਇਹ ਫਿਰ ਵੀ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨਾਂ ਅਤੇ ਇੱਕ ਰੀਫ੍ਰੈਸ਼ ਫਲੋ ਨਾਲ ਜੋੜੋ।
localStorage/sessionStorage ਆਸਾਨ ਹਨ ਪਰ ਖਤਰਨਾਕ: ਕੋਈ ਵੀ XSS ਕਮਜ਼ੋਰੀ ਟੋਕਨਾਂ ਨੂੰ ਵ੍ਹਿਸ਼ਲਾ ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਵਰਤਦੇ ਹੋ, ਤਾਂ XSS ਰੋਕਥਾਮ (CSP, ਆਉਟਪੁੱਟ ਐਸਕੇਪਿੰਗ, ਡਿਪੈਂਡੇੰਸੀ ਹਾਈਜੀਨ) ਨੂੰ ਨੌਨ-ਨੇਗੋਸ਼ੀਏਬਲ ਸਮਝੋ ਅਤੇ ਟੋਕਨਾਂ ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਰੱਖੋ।
Secure cookies (ਵੈਬ ਲਈ ਅਕਸਰ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ) ਟੋਕਨ HttpOnly ਕੁਕੀ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ JavaScript ਇਸਨੂੰ ਪੜ੍ਹ ਨਾ ਸਕੇ—ਇਸ ਨਾਲ XSS ਨਾਲ ਟੋਕਨ ਚੋਰੀ ਦਾ ਪ੍ਰਭਾਵ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਟਰੇਡ-ਆਫ ਹੈ CSRF ਦਾ ਖਤਰਾ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਆਪਣੇ ਆਪ ਕੁਕੀਆਂ ਜੁੜਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਕੁਕੀ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਸੈੱਟ ਕਰੋ:
HttpOnlySecure (ਸਿਰਫ਼ HTTPS)SameSite=Lax ਜਾਂ SameSite=Strict (SameSite=None; Secure ਕੁਝ ਕ੍ਰਾਸ-ਸਾਈਟ ਫਲੋਜ਼ ਲਈ ਲੋੜੀਂਦਾ ਹੋ ਸਕਦਾ ਹੈ)ਸਟੇਟ-ਚੇਨਜਿੰਗ ਰਿਕਵੇਸਟਾਂ ਲਈ CSRF ਟੋਕਨਾਂ ਬਾਰੇ ਵੀ ਸੋਚੋ।
iOS/Android 'ਤੇ, ਟੋਕਨਾਂ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੀ ਸਰਕਿਊਰ ਸਟੋਰੇਜ (Keychain / Keystore-backed storage) ਵਿੱਚ ਰੱਖੋ। ਸਧਾਰਨ ਫਾਇਲਾਂ ਜਾਂ ਪ੍ਰੇਫਰੰਸਾਂ ਤੋਂ ਬਚੋ। ਜੇ ਤੁਹਾਡਾ ਥਰੈਟ ਮਾਡਲ ਰੂਟਡ/ਜੇਲਬ੍ਰੋਕਨ ਉਪਕਰਨਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਨਿਕਾਸ ਸੰਭਵ ਮੰਨੋ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਟੋਕਨ ਅਤੇ ਸਰਵਰ-ਪਾਸੇ ਨਿਯੰਤਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹੋ।
ਟੋਕਨ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਉਸਨੂੰ ਸੀਮਤ ਕਰੋ: ਘੱਟੋ-ਘੱਟ ਸਕੋਪ/ਕਲੇਮ ਵਰਤੋ, access ਟੋਕਨਾਂ ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਰੱਖੋ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦਾ ਇੰਬੇਡਿੰਗ ਟਾਲੋ।
JWT ਆਸਾਨ ਹਨ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਇਨਸੀਡੈਂਟ ਪ੍ਰਿਡਿਕਟੇਬਲ ਗਲਤੀਆਂ ਤੋਂ ਹੁੰਦੇ ਹਨ। ਇੱਕ JWT ਨੂੰ ਨੋਟਾਂ ਵਾਂਗ ਸੋਚੋ: ਜਿਸਨੇ ਵੀ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਲਿਆ ਉਹ ਅਕਸਰ ਇਸਨੂੰ ਖਰਚ ਵੀ ਕਰ ਸਕਦਾ ਹੈ।
ਜੇ ਟੋਕਨ ਕਈ ਦਿਨ ਜਾਂ ਹਫਤੇ ਵਾਸਤੇ ਰਿਹਾ, ਤਾਂ ਲੀਕ ਹੋਣ 'ਤੇ ਹਮਲਾਵਰ ਨੂੰ ਉਹ ਬਾਰਾ ਵਿੰਡੋ ਮਿਲ ਜਾਂਦੀ ਹੈ।
ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨ (ਕਈ ਮਿੰਟ) ਪਸੰਦ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਮਕੈਨਿਜ਼ਮ ਰਾਹੀਂ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ। ਜੇ "ਮੈਨੇ ਰਿਮੈਮਬਰ ਮੀ" ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨਾਂ ਅਤੇ ਸਰਵਰ-ਪਾਸੇ ਨਿਯੰਤਰਨਾਂ ਨਾਲ ਕਰੋ।
ਸੱਚਾ ਸਿਗਨੇਚਰ ਹੀ ਕਾਫੀ ਨਹੀਂ। iss ਅਤੇ aud ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਸਮੇਂ-ਆਧਾਰਿਤ claims ਜਿਵੇਂ exp ਅਤੇ nbf ਨੂੰ ਵੈਲਿਡੇਟ ਕਰੋ।
ਡੇਕੋਡਿੰਗ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਹਮੇਸ਼ਾ ਸਰਵਰ 'ਤੇ ਸਿਗਨੇਚਰ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਅਧਿਕਾਰ ਸਰਵਰ-ਪਾਸੇ ਲਾਗੂ ਕਰੋ।
alg ਨੂੰ ਸਹੀ ਸਮਝ ਕੇ ਹੀ ਸਵੀਕਾਰੋ। allowlist ਰੱਖੋ।JWTs ਨੂੰ ਕੁਇਰੀ ਪੈਰਾਮਜ਼ ਵਿੱਚ ਨਾ ਰੱਖੋ। ਉਹ ਬਰਾਊਜ਼ਰ ਇਤਿਹਾਸ, ਸਰਵਰ ਲਾਗ, ਐਨਲਿਟਿਕਸ ਟੂਲ ਅਤੇ ਰੈਫਰਰ ਹੈਡਰਾਂ ਵਿੱਚ ਆ ਸਕਦੇ ਹਨ।
ਇਸਦੀ ਥਾਂ Authorization: Bearer ... ਵਰਤੋ।
ਮੰਨੋ ਕਿ ਕੁੰਜੀਆਂ ਅਤੇ ਟੋਕਨ ਲੀਕ ਹੋ ਸਕਦੇ ਹਨ। ਸਾਈਨਿੰਗ ਕੀਜ਼ ਰੋਟੇ ਕਰੋ, kid ਵਰਤਕੇ ਨਰਮ ਰੋਟੇਸ਼ਨ ਸਹਾਇਤ ਕਰੋ, ਅਤੇ ਇੱਕ ਰਿਵੋਕੇਸ਼ਨ ਯੋਜਨਾ (ਛੋਟੀ ਮਿਆਦ + ਖਾਤਾ/ਸੈਸ਼ਨ ਡਿਸੇਬਲ ਕਰਨ di ਸਮਰੱਥਾ) ਰੱਖੋ। ਸਟੋਰੇਜ ਗਾਈਡੈਂਸ ਲਈ ਦੇਖੋ /blog/where-to-store-jwts-safely।
JWT ਲਾਭਕਾਰੀ ਹਨ, ਪਰ ਇਹ ਹਰ ਹਾਲਤ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਨਹੀਂ ਹੁੰਦੇ। ਅਸਲ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਇੱਕ self-contained ਟੋਕਨ ਤੋਂ ਫਾਇਦਾ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਲੁੱਕਅੱਪ ਤੋਂ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
ਪਾਰੰਪਰਿਕ ਸਰਵਰ-ਰੈਂਡਰ ਕੀਤੇ ਵੈੱਬ ਐਪਾਂ ਲਈ ਜਿਥੇ ਸਿੱਧੇ ਅਮਲ ਨਾਲ ਇਨਵੈਲਿਡੇਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਸਰਵਰ-ਸਾਈਡ ਸੈਸ਼ਨਸ ਨੂੰ HttpOnly ਕੁਕੀਆਂ ਨਾਲ ਅਕਸਰ ਸਧਾਰਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ।
ਜੇ ਤੁਹਾਨੂੰ ਸਟੇਟਲੈਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਤੁਸੀਂ ਟੋਕਨਾਂ ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ JWT ਚੁਣੋ।
ਟਾਲੋ JWT ਜਦੋਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਰਿਵੋਕੇਸ਼ਨ ਚਾਹੀਦੀ ਹੋਵੇ, ਤੁਸੀਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਟੋਕਨ ਵਿੱਚ ਰੱਖ ਰਹੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਸੈਸ਼ਨ ਕੁਕੀ ਵਰਤ ਸਕਦੇ ਹੋ।
ਸਹੀ ਕੀ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਅਲਗੋਰਿਦਮ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ। ਗਲਤ ਸਿਗਨੇਚਰ ਨੂੰ ਰੱਦ ਕਰੋ—ਕੋਈ ਛੂਟ ਨਹੀਂ।
exp (ਮਿਆਦ)ਪੱਕਾ ਕਰੋ ਕਿ ਟੋਕਨ ਦੀ ਮਿਆਦ ਖਤਮ ਨਹੀਂ ਹੋਈ।
nbf (not before)ਜੇ ਮੌਜੂਦ ਹੋਵੇ ਤਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਟੋਕਨ ਬਚੋਂ ਪਹਿਲਾਂ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਰਿਹਾ।
aud (audience)ਪੱਖ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਟੋਕਨ ਤੁਹਾਡੇ API/ਸੇਵਾ ਲਈ ਹੀ ਬਣਾਇਆ ਗਿਆ ਹੈ।
iss (issuer)ਪੱਕਾ ਕਰੋ ਕਿ ਟੋਕਨ ਉਮੀਦ ਕੀਤੇ issuer ਵੱਲੋਂ ਆਇਆ ਹੈ।
ਟੋਕਨ ਫਾਰਮੈਟ ਵੈਧ ਕਰੋ, ਅਧਿਕਤਮ ਆਕਾਰ ਲਗਾਓ, ਅਤੇ ਅਚਾਨਕ claim ਕਿਸਮਾਂ ਨੂੰ ਰੱਦ ਕਰੋ ਤਾਂ ਜੋ ਐਜ-ਕੇਸ ਬੱਗ ਘਟ ਸਕਣ।
HS256 (symmetric key): ਇੱਕ ਸਾਂਝਾ ਸੇਕ੍ਰੇਟ ਨਾਲ ਸਾਈਨ ਅਤੇ ਵੈਰੀਫਾਈ ਹੁੰਦਾ ਹੈ。
RS256 / ES256 (asymmetric keys): ਪ੍ਰਾਈਵੇਟ ਕੀ ਸਾਈਨ ਕਰਦੀ ਹੈ; ਪਬਲਿਕ ਕੀ ਵੈਰੀਫਾਈ ਕਰਦੀ ਹੈ。
ਨਿਯਮ: ਜੇ ਇੱਕ ਤੋਂ ਵੱਧ ਸੁਤੰਤਰ ਸਿਸਟਮਾਂ ਨੂੰ ਟੋਕਨ ਵੈਰੀਫਾਈ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਜਾਂ ਤੁਸੀਂ ਹਰ ਵੈਰੀਫਾਇਰ 'ਤੇ ਪੂਰਾ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ), ਤਾਂ RS256/ES256 ਨੂੰ ਤਰਜੀਹ ਦਿਓ।
iss, aud, ਅਤੇ ਨੀਤੀ ਮਨਜ਼ੂਰ ਹੋਏ ਤਾਂ ਯੂਜ਼ਰ ID) ਲੌਗ ਕਰੋ।ਕੀ JWT ਇੰਕ੍ਰਿਪਟਡ ਹੈ?
ਮੂਲ ਰੂਪ ਵਿੱਚ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ JWTs ਸਾਈਂ ਕੀਤੇ ਹੁੰਦੇ ਹਨ, ਇਨਕ੍ਰਿਪਟਡ ਨਹੀਂ।
ਜੇ ਗੁਪਤਤਾ ਚਾਹੀਦੀ ਹੈ ਤਾਂ JWE ਜਾਂ JWT ਵਿੱਚੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਬਾਹਰ ਰੱਖੋ।
ਕੀ ਮੈਂ JWT ਰੱਦ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?
ਜੇ ਤੁਸੀਂ ਕੇਵਲ self-contained access tokens 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਇਹ ਅਸਾਨ ਨਹੀਂ। ਆਮ ਅਪ੍ਰੋਚਾਂ ਵਿੱਚ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨ, high-risk ਘਟਨਾਵਾਂ ਲਈ deny-lists, ਜਾਂ ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨ ਰੋਟੇਸ਼ਨ ਸ਼ਾਮਿਲ ਹਨ।
exp ਕਿੰਨੀ ਲੰਬੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?
ਜਿੰਨੀ ਛੋਟੀ ਹੋ ਸਕੇ ਉਤਨੀ ਛੋਟੀ—ਤੁਹਾਡੀ UX ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਇਜਾਜ਼ਤ ਮਦਦਗਾਰ ਹੈ। ਕਈ APIs access ਟੋਕਨਾਂ ਲਈ ਮਿੰਟ ਵਰਤਦੇ ਹਨ ਅਤੇ ਲੰਬੇ ਸੈਸ਼ਨ ਲਈ ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨ ਵਰਤਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਨਵੇਂ API ਜਾਂ SPA ਵਿੱਚ JWT ਅਥੇਨ ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਦੁਹਰਾਉਣਯੋਗ ਹੁੰਦਾ ਹੈ: ਮਿਡਲਵੇਅਰ ਵਾਇਰਿੰਗ, iss/aud/exp ਦੀ ਜਾਂਚ, ਕੁਕੀ ਫਲੈਗ ਸੈਟ ਕਰਨਾ, ਅਤੇ ਲੌਗਾਂ ਤੋਂ ਟੋਕਨ ਹਟਾਉਣਾ।
Koder.ai ਨਾਲ, ਤੁਸੀਂ ਗੱਲ-ਬਾਤ-ਚਲਾਉਣ ਵਾਲੇ ਵਰਕਫਲੋ ਰਾਹੀਂ ਇੱਕ ਵੈੱਬ ਐਪ (React), ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ (Go + PostgreSQL), ਜਾਂ ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ ਤੇ ਜੀ-ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ—ਫਿਰ planning mode ਵਿੱਚ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਬਨਾਓ, snapshots ਅਤੇ rollback ਵਰਤੋ, ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ। ਇਹ JWT-ਆਧਾਰਿਤ ਅਥੇਨ ਫਲੋਜ਼ ਬਣਾਉਣ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਾਜਿਕ, ਕੀ ਰੋਟੇਸ਼ਨ ਰਣਨੀਤੀ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਜ਼ 'ਤੇ ਕੰਟਰੋਲ ਦੇਂਦਾ ਹੈ।
JWT (JSON Web Token) ਇੱਕ ਕੰਪੈਕਟ, URL-ਸੇਫ਼ ਸਤਰ ਹੈ ਜੋ ਦਾਅਵੇ (ਡਾਟਾ ਫੀਲਡ) ਲੈ ਕੇ ਚਲਦਾ ਹੈ ਅਤੇ ਸਰਵਰ ਵੱਲੋਂ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ API ਦੀਆਂ ਰਿਕਵੇਸਟਾਂ 'ਤੇ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਵਜੋਂ:
Authorization: Bearer \u003ctoken\u003eਮੁੱਖ ਗੱਲ: ਸਰਵਰ ਟੋਕਨ ਦੀ ਸਿਗਨੇਚਰ ਰਾਹੀਂ ਇੰਟੀਗ੍ਰਿਟੀ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਹਰ ਯੂਜ਼ਰ ਲਈ ਇੱਕ ਸੈਸ਼ਨ ਰਿਕਾਰਡ ਰੱਖੇ।
ਸੈਸ਼ਨ ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਆਮ ਤੌਰ 'ਤੇ ਸਰਵਰ 'ਤੇ ਸਟੇਟ ਰੱਖਦਾ ਹੈ (ਸੈਸ਼ਨ ਰਿਕਾਰਡ ਜੋ ਇੱਕ ਕੁਕੀ/ਸੈਸ਼ਨ ID ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ)। JWT-ਆਧਾਰਿਤ ਅਥੇਨ ਵਿੱਚ, ਕਲਾਇੰਟ ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਇੱਕ ਸਾਈਂ ਕੀਤਾ ਹੋਇਆ ਟੋਕਨ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ API ਉਸਨੂੰ ਵੈਰੀਫਾਈ ਕਰਦਾ ਹੈ。
JWT APIs ਅਤੇ ਬਹੁ-ਸੇਵਾ ਆਰਕੀਟੈਕਚਰ ਲਈ ਲੋਕਪ੍ਰਿਯ ਹਨ ਕਿਉਂਕਿ ਜਾਂਚ ਨੂੰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਸਾਂਝੇ ਸੈਸ਼ਨ ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਘੱਟ ਹੁੰਦੀ ਹੈ।
"ਸਟੇਟਲੈਸ" ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਕਦੇ ਵੀ ਸਰਵਰ-ਪਾਸੇ ਜਾਂਚ ਨਹੀਂ ਹੁੰਦੀ—ਅਸਲ ਸਿਸਟਮ ਅਕਸਰ ਰਿਵੋਕੇਸ਼ਨ ਲਿਸਟਾਂ, ਯੂਜ਼ਰ ਸਥਿਤੀ ਜਾਂ ਸਕੀਮਾਂ ਲਈ ਕੀ ਰੋਟੇਸ਼ਨ ਵਰਗੀਆਂ ਚੈਕ ਕਰਦੇ ਹਨ।
JWT ਤਿੰਨ Base64URL-ਇਨਕੋਡ ਕੀਤੀਆਂ ਭਾਗਾਂ ਨਾਲ ਬਣਿਆ ਹੁੰਦਾ ਹੈ ਜੋ ਡੋਟ ਨਾਲ ਵੱਖਰੇ ਹੁੰਦੇ ਹਨ:
header.payload.signatureਹੈਡਰ ਦੱਸਦਾ ਹੈ ਕਿ ਇਹ ਕਿਵੇਂ ਸਾਈਂ ਕੀਤਾ ਗਿਆ, ਪੇਲੋਡ ਵਿੱਚ ਦਾਅਵੇ ਹਨ (ਜਿਵੇਂ sub, exp, aud) ਅਤੇ ਸਿਗਨੇਚਰ ਟੋਕਨ ਦੀ ਚੇਨਾਬੰਦੀ ਦੀ ਪਛਾਣ ਲਈ ਹੈ।
ਨਹੀਂ। ਮਿਆਰੀ JWT ਆਮ ਤੌਰ 'ਤੇ ਸਾਈਂ ਹੁੰਦੇ ਹਨ, ਏਨਕ੍ਰਿਪਟਡ ਨਹੀਂ।
ਜੇ ਤੁਹਾਨੂੰ ਗੁਪਤਤਾ ਚਾਹੀਦੀ ਹੈ ਤਾਂ JWE (ਇੰਕ੍ਰਿਪਟਡ ਟੋਕਨ) ਵਰਗੇ ਫਾਰਮੈਟ ਦੀ ਸੋਚੋ ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਸਰਵਰ-ਸਾਈਡ ਰੱਖੋ ਅਤੇ ਕੇਵਲ ਇੱਕ ਰੇਫਰੈਂਸ ਟੋਕਨ ਵਿੱਚ ਰੱਖੋ।
ਸਿਗਨੇਚਰ ਸਰਵਰ ਨੂੰ ਇਹ ਵੈਰੀਫਾਈ ਕਰਨ ਦਿੰਦੀ ਹੈ ਕਿ ਟੋਕਨ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ ਅਤੇ ਜਿਸਨੇ ਜਾਰੀ ਕੀਤਾ ਉਹ ਭਰੋਸੇਯੋਗ ਹੈ।
ਇਹ ਨਹੀਂ ਦਿਖਾਉਂਦਾ:
exp ਤੋਂ ਪਹਿਲਾਂ ਆਟੋਮੈਟਿਕ ਰਿਵੋਕੇਸ਼ਨਟੋਕਨ ਨੂੰ ਇੱਕ ਕ੍ਰੈਡੈਂਸ਼ਲ ਵਾਂਗ ਸੋਚੋ: ਜੇ ਇਹ ਲੀਕ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਮਿਆਦ ਤੱਕ ਦੁਬਾਰਾ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।
alg ਵੈਰੀਫਾਇਰ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਅਲਗੋਰਿਦਮ ਵਰਤਿਆ ਗਿਆ (ਉਦਾਹਰਨ HS256 vs RS256)। kid ਇੱਕ ਕੀ-ਆਈਡ ਹੈ ਜੋ ਕੀ ਰੋਟੇਸ਼ਨ ਸਮੇਂ ਸਹੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕੁੰਜੀ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ。
ਸੁਰੱਖਿਆ ਨਿਯਮ:
ਮਿਆਰੀ ਰਜਿਸਟਰਡ ਕਲੇમਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਕਸਟਮ ਕਲੇਮਾਂ ਨਿयੂਨੀਤਮ ਰੱਖੋ。
ਆਮ ਰਜਿਸਟਰਡ ਕਲੇਮਾਂ:
JWT ਇੱਕ ਟੋਕਨ ਫਾਰਮੈਟ ਹੈ; OAuth 2.0 ਅਤੇ OpenID Connect ਪ੍ਰੋਟੋਕੋਲ ਹਨ。
ਆਮ ਤੌਰ 'ਤੇ:
ਜ਼ਰੂਰੀ: ID token ਨੂੰ API ਨੂੰ ਕਾਲ ਕਰਨ ਲਈ ਵਰਤੋ ਨਾ, ਜੇਕਰ ਜੋ ਕਿ access token ਹੋਵੇ।
ਬ੍ਰਾਉਜ਼ਰ ਲਈ ਆਮ ਵਿਕਲਪ ਹਨ:
ਜੋ ਵੀ ਚੁਣੋ, access tokens ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਰੱਖੋ ਅਤੇ ਟੋਕਨ ਅਧਿਕਾਰਾਂ ਘਟਾਓ।
ਘੱਟੋ-ਘੱਟ ਜਾਂਚ ਕਰੋ:
exp (ਮਿਆਦ ਖਤਮ)iss (ਉਮੀਦ ਕੀਤਾ ਗਿਆ issuer)aud (ਤੁਹਾਡੇ API ਲਈ ਹੀ ਟੋਕਨ)nbf (ਜੇ ਮੌਜੂਦ ਹੋ)ਹੋਰ ਗਾਰਡਰੇਲਜ਼:
algalg: "none" ਕਦੇ ਵੀ ਸਵੀਕਾਰ ਨਾ ਕਰੋ।kid ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਕੀ ਲੁੱਕਅੱਪ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦਿਓ।iss (issuer)sub (subject / ਯੂਜ਼ਰ ID)aud (audience / ਮਨਜ਼ੂਰ ਕੀਤਾ ਗਿਆ API)exp (expiration)iat (issued at)nbf (not before)ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਂ ਰਾਜ਼ ਖੋਜ ਕਰਨ ਯੋਗ ਡਾਟਾ ਨੂੰ ਕਦੇ ਵੀ ਪੇਲੋਡ ਵਿੱਚ ਨਾ ਰੱਖੋ।