JWT ਕੀ ਹੈ? JSON Web Tokens ਲਈ ਸਪੱਸ਼ਟ ਗਾਈਡ

JWT ਸਰਲ ਸ਼ਬਦਾਂ ਵਿੱਚ

A JWT (JSON Web Token) ਇੱਕ ਕੰਪੈਕਟ, URL-ਸੇਫ਼ ਸਤਰ ਹੈ ਜੋ ਇੱਕ ਵਰਤੋਂਕਾਰ ਜਾਂ ਸੈਸ਼ਨ ਬਾਰੇ ਤੱਥ (ਆਮ ਤੌਰ 'ਤੇ) ਦਰਸਾਉਂਦਾ ਹੈ ਅਤੇ ਸਿਸਟਮਾਂ ਦਰਮਿਆਨ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਅਕਸਰ ਇਹ ਇੱਕ ਲੰਮਾ ਮੁੱਲ ਹੁੰਦਾ ਹੈ ਜੋ eyJ... ਵਰਗੇ ਪ੍ਰੀਫਿਕਸ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਅਤੇ HTTP ਹੈਡਰ ਵਿੱਚ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ Authorization: Bearer \u003ctoken\u003e.

ਟੋਕਨ ਦੀ ਜ਼ਰੂਰਤ ਕਿਉਂ?

ਪੰਰਪਰਾ अनुसार ਲੌਗਿਨਸ ਅਕਸਰ ਸਰਵਰ ਸੈਸ਼ਨ ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ: ਤੁਹਾਡੇ ਸਾਇਨ-ਇਨ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਸਰਵਰ ਸੈਸ਼ਨ ਡੇਟਾ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ ਇਕ ਸੈਸ਼ਨ ID ਕੁਕੀ ਦਿੰਦਾ ਹੈ। ਹਰ ਰਿਕਵੇਸਟ ਉਹ ਕੁਕੀ ਸ਼ਾਮਿਲ ਕਰਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਸੈਸ਼ਨ ਨੂੰ ਲੁੱਕਅੱਪ ਕਰਦਾ ਹੈ।

ਟੋਕਨ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣੀਕਰਨ ਨਾਲ, ਸਰਵਰ ਹਰ ਯੂਜ਼ਰ ਰਿਕਵੇਸਟ ਲਈ ਸਟੇਟ ਰੱਖਣ ਤੋਂ ਬਚ ਸਕਦਾ ਹੈ। ਇਸਦੀ ਥਾਂ, ਕਲਾਇੰਟ ਇੱਕ ਟੋਕਨ (ਜਿਵੇਂ JWT) ਰੱਖਦਾ ਹੈ ਅਤੇ API ਕਾਲਾਂ ਨਾਲ ਇਸਨੂੰ ਭੇਜਦਾ ਹੈ। ਇਹ APIs ਲਈ ਲੋਕਪ੍ਰਿਯ ਹੈ ਕਿਉਂਕਿ ਇਹ:

• ਬਹੁਤ ਸੇ ਸਰਵਿਸਿਜ਼ (API ਗੇਟਵੇ, ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼) ਵਿਚ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ
• ਮੋਬਾਈਲ ਅਤੇ ਸਿੰਗਲ-ਪੇਜ ਐਪ (SPA) ਲਈ ਉਚਿਤ ਹੈ ਜੋ ਸਿੱਧਾ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ
• ਸਰਵਰਾਂ ਦਰਮਿਆਨ ਸਾਂਝੇ ਸੈਸ਼ਨ ਸਟੋਰੇਜ ਦੀ ਲੋੜ ਘਟਾਂਦਾ ਹੈ

ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਨੁਆਨਸ: “stateless” ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ “ਕਦੇ ਵੀ ਸਰਵਰ-ਪਾਸੇ ਜਾਂਚ ਨਹੀਂ।” ਬਹੁਤ ਸਾਰੇ ਅਸਲ ਸਿਸਟਮ ਟੋਕਨਾਂ ਨੂੰ ਯੂਜ਼ਰ ਸਥਿਤੀ, ਕੀ ਰੋਟੇਸ਼ਨ, ਜਾਂ ਰਿਵੋਕੇਸ਼ਨ ਮਕੈਨਿਜ਼ਮਾਂ ਵੱਲੋਂ ਵੀ ਵੈਰੀਫਾਈ ਕਰਦੇ ਹਨ।

ਪ੍ਰਮਾਣੀਕਰਨ বনਾਮ ਅਧਿਕਾਰ (ਆਮ ਭਾਸ਼ਾ)

• Authentication (ਪਹਚਾਣ) ਦਾ ਸਵਾਲ: ਤੁਸੀਂ ਕੌਣ ਹੋ? (ਤੁਸੀਂ ਸਾਈਨ-ਇਨ ਕਰਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਪਛਾਣ ਸਾਬਿਤ ਕਰਦੇ ਹੋ.)
• Authorization (ਅਧਿਕਾਰ) ਦਾ ਸਵਾਲ: ਤੁਹਾਨੂੰ ਕੀ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਹੈ? (ਤੁਸੀਂ ਇਨਵੌਇਸ ਪੜ੍ਹ ਸਕਦੇ ਹੋ, ਪ੍ਰੋਜੈਕਟ ਸੋਧ ਸਕਦੇ ਹੋ, ਐਡਮਿਨ ਪੇਜਾਂ ਤਕ ਪਹੁੰਚ ਰੱਖ ਸਕਦੇ ਹੋ ਆਦਿ.)

JWT ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਦਾ ਸਬੂਤ (ਤੁਸੀਂ ਸਾਈਂ-ਇਨ ਹੋ) ਅਤੇ ਮੂਲ ਅਧਿਕਾਰ ਸੰਕੇਤ (ਰੋਲ, ਅਧਿਕਾਰ, ਸਕੋਪ) ਰੱਖਦੇ ਹਨ—ਪਰ ਸਰਵਰ ਨੂੰ ਫਿਰ ਵੀ ਅਧਿਕਾਰ ਨਿਯਮ ਲਾਗੂ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।

JWT ਕਿੱਥੇ ਵਰਤੀਦੇ ਹਨ

ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ JWTs ਨੂੰ ਐਕਸੈਸ ਟੋਕਨ ਵਜੋਂ ਵੇਖੋਗੇ:

• ਵੈੱਬ APIs
• SPAs
• ਮੋਬਾਈਲ ਐਪਾਂ
• ਉਹ ਸਿਸਟਮ ਜੋ OAuth 2.0 ਜਾਂ OpenID Connect (OIDC) ਵਰਤਦੇ ਹਨ

JWT ਦੀ ਬਣਤਰ: ਹੈਡਰ, ਪੇਲੋਡ ਅਤੇ ਸਿਗਨੇਚਰ

ਇੱਕ JWT ਇੱਕ ਕੰਪੈਕਟ ਸਤਰ ਹੈ ਜੋ ਤਿੰਨ ਭਾਗਾਂ ਤੋਂ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਹਰ ਇੱਕ base64url-ਇਨਕੋਡ ਅਤੇ ਡੌਟ ਨਾਲ ਵੱਖਰੇ:

header.payload.signature

ਉਦਾਹਰਨ (ਸੰਖਿਪਤ):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…

1) ਹੈਡਰ

Header ਦੱਸਦਾ ਹੈ ਕਿ ਟੋਕਨ ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ—ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਸਾਈਨਿੰਗ ਅਲਗੋਰਿਦਮ ਹੈ (ਉਦਾਹਰਨ HS256, RS256/ES256) ਅਤੇ ਟੋਕਨ ਦੀ ਕਿਸਮ।

ਆਮ ਖੇਤਰ:

• typ: ਅਕਸਰ "JWT" (ਅਮਲ ਵਿੱਚ ਅਕਸਰ ਨਜ਼ਰਅੰਦਾਜ਼)
• alg: ਵਰਤੀ ਗਈ ਸਾਈਨਿੰਗ ਅਲਗੋਰਿਦਮ
• kid: ਕੀ ਆਈਡੈਂਟੀਫਾਇਰ ਜੋ ਰੋਟੇਸ਼ਨ ਦੌਰਾਨ ਵੈਰੀਫਾਇਰ ਨੂੰ ਸਹੀ ਕੀ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ

ਸੁਰੱਖਿਆ ਨੋਟ: ਹੈਡਰ 'ਤੇ ਅੰਨ੍ਹੇ ਰੂਪ ਵਿੱਚ ਭਰੋਸਾ ਨਾ ਕਰੋ। ਉਹ ਅਲਗੋਰਿਦਮ ਜੋ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ ਉਹਨਾਂ ਦੀ allowlist ਲਗਾਓ ਅਤੇ alg: "none" ਨੂੰ ਕਦੇ ਵੀ ਸਵੀਕਾਰ ਨਾ ਕਰੋ।

2) ਪੇਲੋਡ

ਪੇਲੋਡ ਉਨ੍ਹਾਂ "claims" (ਫ਼ੀਲਡ) ਨੂੰ ਰੱਖਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਅਤੇ ਟੋਕਨ ਸੰਦਰਭ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਿੰਦੇ ਹਨ: ਟੋਕਨ ਕਿਸ ਲਈ ਹੈ, ਕਿਸਨੇ ਜਾਰੀ ਕੀਤਾ, ਅਤੇ ਕਦੋਂ ਇਹ ਖਤਮ ਹੋ ਜਾਵੇਗਾ।

ਮਹੱਤਵਪੂਰਨ: JWT ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਨਕ੍ਰਿਪਟਡ ਨਹੀਂ ਹੁੰਦੇ। Base64url ਇੰਕੋਡਿੰਗ ਟੋਕਨ ਨੂੰ URL-ਸੇਫ਼ ਬਣਾਉਂਦੀ ਹੈ; ਇਹ ਡੇਟਾ ਨੂੰ ਛੁਪਾਉਂਦੀ ਨਹੀਂ।

ਇਸ ਲਈ ਰਾਫ਼ਤਾਂ (passwords, API keys) ਜਾਂ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿੱਜੀ ਡੇਟਾ JWT ਵਿੱਚ ਨਹੀਂ ਰੱਖਣੀ ਚਾਹੀਦੀ।

3) ਸਿਗਨੇਚਰ

Signature ਹੈਡਰ + ਪੇਲੋਡ ਨੂੰ ਇੱਕ ਕੀ ਨਾਲ ਸਾਈਨ ਕਰਕੇ ਬਣਦੀ ਹੈ:

• HS256: ਇੱਕ ਸਾਂਝਾ ਸੇਕ੍ਰੇਟ ਸਾਈਨ ਅਤੇ ਵੈਰੀਫਾਈ ਕਰਦਾ ਹੈ
• RS256/ES256: ਪ੍ਰਾਈਵੇਟ ਕੀ ਸਾਈਨ ਕਰਦੀ ਹੈ; ਪਬਲਿਕ ਕੀ ਵੈਰੀਫਾਈ ਕਰਦੀ ਹੈ

ਸਿਗਨੇਚਰ ਇੰਟੀਗ੍ਰਿਟੀ ਦਿੰਦੀ ਹੈ: ਇਹ ਸਰਵਰ ਨੂੰ ਯਕੀਨ ਦਿਵਾਉਂਦਾ ਹੈ ਕਿ ਟੋਕਨ ਤਬਦੀਲ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸਾਈਨਰ ਨੇ ਬਣਾਇਆ। ਇਹ ਗੁਪਤਤਾ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦੀ।

ਆਕਾਰ ਬਾਰੇ ਸੋਚ

ਕਿਉਂਕਿ JWT ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਹੈਡਰ ਅਤੇ ਪੇਲੋਡ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ, ਵੱਡੇ ਟੋਕਨ ਬੈਂਡਵਿਡਥ ਅਤੇ ਓਵਰਹੈਡ ਵਧਾਉਂਦੇ ਹਨ। claims ਨੂੰ ਸੰਕੁਚਿਤ ਰੱਖੋ ਅਤੇ ਭਾਰੀ ਡੇਟਾ ਦੀ ਥਾਂ ਸਿਰਫ਼ ਸੂਚਕ (ID) ਰੱਖੋ।

ਪੇਲੋਡ ਅਤੇ claims: ਕੀ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ (ਅਤੇ ਕੀ ਨਹੀਂ)

Claims ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਕਿਸਮਾਂ ਵਿੱਚ ਹੋਂਦੀਆਂ ਹਨ: registered (ਸਟੈਂਡਰਡ ਨਾਮ) ਅਤੇ custom (ਆਪ ਦੀ ਐਪ ਦੇ ਖੇਤਰ)।

ਆਮ registered claims

• iss (issuer): ਟੋਕਨ ਕਿਸਨੇ ਬਣਾਇਆ
• sub (subject): ਟੋਕਨ ਕਿਸ ਬਾਰੇ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ ID)
• aud (audience): ਟੋਕਨ ਕਿਸ ਲਈ ਹੈ (ਉਦਾਹਰਨ ਲਈ ਕੋਈ ਨਿਰਧਾਰਿਤ API)
• exp (expiration time): ਕਦੋਂ ਟੋਕਨ ਸਵੀਕਾਰ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇ
• iat (issued at): ਟੋਕਨ ਕਦੋਂ ਬਣਿਆ
• nbf (not before): ਇਸ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਟੋਕਨ ਸਵੀਕਾਰ ਨਾ ਕੀਤਾ ਜਾਵੇ

ਕਸਟਮ claims: ਸਮਝਦਾਰੀ ਨਾਲ ਰੱਖੋ

ਸਿਰਫ਼ ਉਹੀ ਡੇਟਾ ਸ਼ਾਮਿਲ ਕਰੋ ਜੋ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੀ ਸੇਵਾ ਨੂੰ ਅਥੇਨ/ਅਧਿਕਾਰ ਫੈਸਲਾ ਕਰਨ ਲਈ ਸਚਮੁਚ ਚਾਹੀਦਾ ਹੈ।

ਚੰਗੇ ਉਦਾਹਰਨ:

• ਇੱਕ ਸਥਿਰ ਆਊਟਲਾਈਨ ਯੂਜ਼ਰ ਆਈਡੀ (user_id)
• ਛੋਟੀ ਰੋਲ/ਅਧਿਕਾਰ ਸੈੱਟ (ਜੇ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਅਪ-ਟੂ-ਡੇਟ ਰੱਖ ਸਕਦੇ ਹੋ)
• ਮਲਟੀ-ਟੇਨੈਂਟ ਐਪਾਂ ਵਿੱਚ ਟੇనੈਂਟ/ਸੰਗਠਨ ID

ਵਹੀ-ਹੀ claims ਜੋ ਬਹੁਤ ਸਾਰਾ ਪ੍ਰੋਫ਼ਾਈਲ ਡੇਟਾ ਨਕਲ ਕਰਦੇ ਹਨ ਉਹ ਬਹੁਤ ਸਤੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਟੋਕਨ ਨੂੰ ਸੁਸਤੀ ਕਰਦੇ ਹਨ ਅਤੇ ਲੀਕ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਵੱਧਦੇ ਹਨ।

JWT ਪੇਲੋਡ ਵਿੱਚ ਕਦੇ ਵੀ ਕੀ ਨਾ ਰੱਖੋ

ਕਿਉਂਕਿ ਪੇਲੋਡ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਕਦੇ ਵੀ ਨਾ ਰੱਖੋ:

• ਪਾਸਵਰਡ, API ਕੀ, ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨ, ਜਾਂ ਕੋਈ ਵੀ ਰਾਜ਼
• ਭੁਗਤਾਨ ਵਿਵਰਣ, ਸਰਕਾਰੀ ID, ਜਾਂ ਹੋਰ ਸੰਵੇਦਨਸ਼ੀਲ ਨਿੱਜੀ ਡੇਟਾ
• ਕੁਝ ਵੀ ਜੋ ਤੁਸੀਂ ਬਰਾਊਜ਼ਰ, ਪ੍ਰੌਕਸੀ ਜਾਂ ਲੌਗ ਤੋਂ ਕਾਡੀ ਕਾਪੀ ਹੋਣ 'ਤੇ ਨਹੀਂ ਚਾਹੁੰਦੇ

ਜੇ ਤੁਹਾਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਉਹਨੂੰ ਸਰਵਰ-ਸਾਈਡ ਸਟੋਰ ਕਰੋ ਅਤੇ ਟੋਕਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਰੇਫਰੈਂਸ (ਜਿਵੇਂ ID) ਰੱਖੋ—ਯਾ ਜਦੋਂ ਲੋੜ ਹੋਵੇ ਤਾਂ ਇੰਕ੍ਰਿਪਟਡ ਟੋਕਨ ਫਾਰਮੈਟ (JWE) ਵਰਤੋ।

ਸਿਗਨੇਚਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ (ਅਤੇ ਕੀ ਗਾਰੰਟੀ ਕਰਦੀ ਹੈ)

ਸਾਈਨਿੰਗ ਇੰਕ੍ਰਿਪਸ਼ਨ ਨਹੀਂ ਹੈ।

• ਸਾਈਨਿੰਗ ਚਿੱਠੀ ਨੂੰ ਸੀਲ ਕਰਨ ਵਰਗੀ ਹੈ: ਲੋਕ ਇਸ ਨੂੰ ਪੜ੍ਹ ਸਕਦੇ ਹਨ, ਪਰ ਉਹ ਚੈਕ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਇਹ ਬਦਲਿਆ ਨਹੀਂ ਗਿਆ।
• ਇੰਕ੍ਰਿਪਸ਼ਨ ਚਿੱਠੀ ਨੂੰ ਬੰਦ ਬਕਸੇ ਵਿੱਚ ਤਾਲਾ ਲਾ ਦੇਣ ਵਰਗੀ ਹੈ: ਕੇਵਲ ਕੁੰਜੀ ਵਾਲਾ ਹੀ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

ਜਦੋ JWT ਜਾਰੀ ਹੁੰਦਾ ਹੈ, ਸਰਵਰ ਹੈਡਰ + ਪੇਲੋਡ ਨੂੰ ਸਾਈਨ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਟੋਕਨ ਬਾਅਦ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਰਵਰ ਸਿਗਨੇਚਰ ਨੂੰ ਦੁਬਾਰਾ ਗਣਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਲਨਾ ਕਰਦਾ ਹੈ। ਜੇ ਕਿਸੇ ਨੇ ਇਕ حرف ਵੀ ਬਦਲਿਆ (ਉਦਾਹਰਣ: "role":"user" ਤੋਂ "role":"admin"), ਵੈਰੀਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋ ਜਾਵੇਗੀ ਅਤੇ ਟੋਕਨ ਰੱਦ ਕੀਤਾ ਜਾਵੇਗਾ।

JWT বনাম OAuth, OpenID Connect, ਅਤੇ ਟੋਕਨ ਕਿਸਮਾਂ

JWT ਇੱਕ ਟੋਕਨ ਫਾਰਮੈਟ ਹੈ। OAuth 2.0 ਅਤੇ OpenID Connect (OIDC) ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਹਨ ਜੋ ਦਰਸਾਉਂਦੇ ਹਨ ਕਿ ਐਪਸ ਟੋਕਨ ਕਿਵੇਂ ਬੇਨਤੀ, ਜਾਰੀ ਅਤੇ ਵਰਤਦੇ ਹਨ।

OAuth 2.0 ਅਤੇ ਐਕਸੈਸ/ਰਿਫ੍ਰੈਸ਼ ਟੋਕਨ

OAuth 2.0 ਮੁੱਖ ਤੌਰ 'ਤੇ ਅਧਿਕਾਰ ਬਾਰੇ ਹੈ: ਇੱਕ ਐਪ ਨੂੰ ਯੂਜ਼ਰ ਦੀ ਪਾਸਵਰਡ ਸਾਂਝੀ ਕੀਤੇ ਬਗੈਰ API ਤੱਕ ਪਹੁੰਚ ਦੇਣ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ।

• Access token: ਇੱਕ API ਨੂੰ ਪੇਸ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਜੋ ਇਜਾਜ਼ਤ ਸਾਬਿਤ ਕੀਤੀ ਜਾ ਸਕੇ; ਇਹ JWT ਹੋ ਸਕਦਾ ਹੈ ਜਾਂ ਇੱਕ opaque ਟੋਕਨ
• Refresh token: ਲੰਬੀ ਮਿਆਦ ਵਾਲਾ ਟੋਕਨ ਜੋ ਨਵੇਂ access tokens ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ

ਐਕਸੈਸ ਟੋਕਨ ਆਮ ਤੌਰ 'ਤੇ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਹੁੰਦੇ ਹਨ (ਕਈ ਮਿੰਟ). ਛੋਟੀ ਮਿਆਦ ਟੋਕਨ ਲੀਕ ਹੋਣ 'ਤੇ ਨੁਕਸਾਨ ਘੱਟ ਕਰਦੀ ਹੈ।

OpenID Connect (OIDC) ਅਤੇ ID ਟੋਕਨ

OIDC OAuth 2.0 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ ਜੋੜਦਾ ਹੈ ਅਤੇ ਇੱਕ ID token ਲਿਆਉਂਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ JWT ਹੁੰਦਾ ਹੈ।

• ID token: client ਐਪ ਲਈ ਯੂਜ਼ਰ ਦੀ ਪਛਾਣ ਦੀ ਪੁਸ਼ਟੀ ਕਰਨ ਲਈ
• Access token: API ਲਈ ਅਧਿਕਾਰ ਦਿੱਤੇ ਜਾਣ ਲਈ

ਇੱਕ ਮੁੱਖ ਨਿਯਮ: ID token ਨੂੰ API ਕਾਲ ਕਰਨ ਲਈ ਵਰਤੋ ਨਾ।

ਜੇ ਤੁਸੀਂ ਪ੍ਰੈਕਟਿਕਲ ਫਲੋਜ਼ ਬਾਰੇ ਹੋਰ ਜਾਣਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog/jwt-authentication-flow ਵੇਖੋ।

ਆਮ JWT ਅਥੇਨ ਫਲੋ

ਇੱਕ ਆਮ ਫਲੋ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:

1) ਲੌਗਿਨ

ਯੂਜ਼ਰ ਸਾਈਨ ਇਨ ਕਰਦਾ ਹੈ (email/password, SSO ਆਦਿ)। ਜੇ ਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਸਰਵਰ ਇੱਕ JWT (ਅਕਸਰ access token) ਬਣਾਉਂਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਮੈਜਰ ਕਲੇਮਾਂ ਜਿਵੇਂ subject ਅਤੇ expiration ਹੁੰਦੇ ਹਨ।

2) ਟੋਕਨ ਜਾਰੀ ਕਰਨਾ

ਸਰਵਰ ਟੋਕਨ ਨੂੰ ਸਾਈਨ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਕਲਾਇੰਟ (ਵੈੱਬ ਐਪ, ਮੋਬਾਈਲ ਐਪ, ਜਾਂ ਹੋਰ ਸੇਵਾ) ਨੂੰ ਵਾਪਸ ਭੇਜਦਾ ਹੈ।

3) API ਕਾਲਾਂ

ਸੁਰੱਖਿਅਤ ਏਂਡਪੋਇੰਟਾਂ ਲਈ, ਕਲਾਇੰਟ JWT ਨੂੰ Authorization ਹੈਡਰ ਵਿੱਚ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ:

Authorization: Bearer \u003cJWT\u003e

4) ਵੈਰੀਫਿਕੇਸ਼ਨ

ਰਿਕਵੇਸਟ ਸਰਵ ਕੀਤਾ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, API ਆਮ ਤੌਰ 'ਤੇ ਜਾਂਚਦਾ ਹੈ:

• ਸਿਗਨੇਚਰ (ਇੰਟੀਗ੍ਰਿਟੀ + ਭਰੋਸੇਯੋਗ issuer)
• exp (ਮਿਆਦ ਖਤਮ ਨਹੀਂ ਹੋਈ)
• iss (ਉਮੀਦ ਕੀਤਾ ਗਿਆ issuer)
• aud (ਇਹ API ਲਈ ਹੈ)

ਜੇ ਸਾਰੀਆਂ ਜਾਂਚਾਂ ਪਾਸ ਹੋਦੀਆਂ ਹਨ, API ਯੂਜ਼ਰ ਨੂੰ ਪ੍ਰਮਾਣਿਤ ਮੰਨਦਾ ਹੈ ਅਤੇ ਅਧਿਕਾਰ ਨਿਯਮ ਲਾਗੂ ਕਰਦਾ ਹੈ (ਉਦਾਹਰਨ: ਰਿਕਾਰਡ-ਲੇਵਲ ਅਧਿਕਾਰ)।

5) ਘੜੀ-ਸਕਿਊਅ ਬਾਰੇ ਛੋਟਾ ਨੋਟ

ਕਿਉਂਕਿ ਸਿਸਟਮ ਘੜੀਆਂ ਥੋੜ੍ਹੀ ਘੁੱਟ-ਫੜ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਬਹੁਤ ਸਾਰੀਆਂ ਸਿਸਟਮ ਟਾਈਮ-ਅਧਾਰਿਤ claims ਜਿਵੇਂ exp ਅਤੇ nbf ਦੀ ਜਾਂਚ ਸਮੇਂ ਛੋਟਾ clock skew ਲਗਾਉਂਦੇ ਹਨ। ਸਕਿਊਅ ਛੋਟਾ ਰੱਖੋ ਤਾਂ ਜੋ ਟੋਕਨ ਦੀ ਮਿਆਦ ਜ਼ਿਆਦਾ ਨਾ ਵਧੇ।

JWTs ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿੱਥੇ ਰੱਖਣਾ

ਸਟੋਰੇਜ ਦੇ ਚੋਣ ਇਹ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ ਕਿ ਹਮਲਾਵਰ ਕਿਸ ਤਰ੍ਹਾਂ ਟੋਕਨ ਚੁਰਾ ਸਕਦਾ ਹੈ ਅਤੇ ਉਹ ਕਿਸ ਹੱਦ ਤੱਕ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦਾ ਹੈ।

ਬ੍ਰਾਊਜ਼ਰ ਐਪ: ਮੈਮਰੀ বনਾਮ localStorage বনਾਮ cookies

In-memory ਸਟੋਰੇਜ (SPA ਲਈ ਅਕਸਰ ਸਿਫਾਰਸ਼ੀ) access token ਨੂੰ JS ਸਟੇਟ ਵਿੱਚ ਰੱਖਦਾ ਹੈ। ਇਹ ਰਿਫ੍ਰੈਸ਼ 'ਤੇ ਕਲੀਅਰ ਹੁੰਦਾ ਹੈ ਅਤੇ ਬਾਦ ਵਿੱਚ ਚੋਰੀ ਹੋਣ ਦਾ ਖਤਰਾ ਘੱਟ ਕਰਦਾ ਹੈ, ਪਰ XSS ਬੱਗ ਦੌਰਾਨ ਇਹ ਫਿਰ ਵੀ ਪੜ੍ਹਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਨੂੰ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨਾਂ ਅਤੇ ਇੱਕ ਰੀਫ੍ਰੈਸ਼ ਫਲੋ ਨਾਲ ਜੋੜੋ।

localStorage/sessionStorage ਆਸਾਨ ਹਨ ਪਰ ਖਤਰਨਾਕ: ਕੋਈ ਵੀ XSS ਕਮਜ਼ੋਰੀ ਟੋਕਨਾਂ ਨੂੰ ਵ੍ਹਿਸ਼ਲਾ ਕਰ ਸਕਦੀ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਵਰਤਦੇ ਹੋ, ਤਾਂ XSS ਰੋਕਥਾਮ (CSP, ਆਉਟਪੁੱਟ ਐਸਕੇਪਿੰਗ, ਡਿਪੈਂਡੇੰਸੀ ਹਾਈਜੀਨ) ਨੂੰ ਨੌਨ-ਨੇਗੋਸ਼ੀਏਬਲ ਸਮਝੋ ਅਤੇ ਟੋਕਨਾਂ ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ ਰੱਖੋ।

Secure cookies (ਵੈਬ ਲਈ ਅਕਸਰ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ) ਟੋਕਨ HttpOnly ਕੁਕੀ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਕਿ JavaScript ਇਸਨੂੰ ਪੜ੍ਹ ਨਾ ਸਕੇ—ਇਸ ਨਾਲ XSS ਨਾਲ ਟੋਕਨ ਚੋਰੀ ਦਾ ਪ੍ਰਭਾਵ ਘੱਟ ਹੁੰਦਾ ਹੈ। ਟਰੇਡ-ਆਫ ਹੈ CSRF ਦਾ ਖਤਰਾ, ਕਿਉਂਕਿ ਬ੍ਰਾਊਜ਼ਰ ਆਪਣੇ ਆਪ ਕੁਕੀਆਂ ਜੁੜਦੇ ਹਨ।

ਜੇ ਤੁਸੀਂ ਕੁਕੀ ਵਰਤਦੇ ਹੋ, ਤਾਂ ਸੈੱਟ ਕਰੋ:

• HttpOnly
• Secure (ਸਿਰਫ਼ HTTPS)
• SameSite=Lax ਜਾਂ SameSite=Strict (SameSite=None; Secure ਕੁਝ ਕ੍ਰਾਸ-ਸਾਈਟ ਫਲੋਜ਼ ਲਈ ਲੋੜੀਂਦਾ ਹੋ ਸਕਦਾ ਹੈ)

ਸਟੇਟ-ਚੇਨਜਿੰਗ ਰਿਕਵੇਸਟਾਂ ਲਈ CSRF ਟੋਕਨਾਂ ਬਾਰੇ ਵੀ ਸੋਚੋ।

ਮੋਬਾਈਲ ਐਪ: OS ਦੇ ਸਰਕਿਊਰ ਸਟੋਰੇਜ ਨੂੰ ਤਰਜੀਹ ਦਿਓ

iOS/Android 'ਤੇ, ਟੋਕਨਾਂ ਨੂੰ ਪਲੇਟਫਾਰਮ ਦੀ ਸਰਕਿਊਰ ਸਟੋਰੇਜ (Keychain / Keystore-backed storage) ਵਿੱਚ ਰੱਖੋ। ਸਧਾਰਨ ਫਾਇਲਾਂ ਜਾਂ ਪ੍ਰੇਫਰੰਸਾਂ ਤੋਂ ਬਚੋ। ਜੇ ਤੁਹਾਡਾ ਥਰੈਟ ਮਾਡਲ ਰੂਟਡ/ਜੇਲਬ੍ਰੋਕਨ ਉਪਕਰਨਾਂ ਨੂੰ ਸ਼ਾਮਿਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਨਿਕਾਸ ਸੰਭਵ ਮੰਨੋ ਅਤੇ ਛੋਟੀ ਮਿਆਦ ਟੋਕਨ ਅਤੇ ਸਰਵਰ-ਪਾਸੇ ਨਿਯੰਤਰਨਾਂ 'ਤੇ ਨਿਰਭਰ ਰਹੋ।

ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ (Least privilege)

ਟੋਕਨ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਉਸਨੂੰ ਸੀਮਤ ਕਰੋ: ਘੱਟੋ-ਘੱਟ ਸਕੋਪ/ਕਲੇਮ ਵਰਤੋ, access ਟੋਕਨਾਂ ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਰੱਖੋ, ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਦਾ ਇੰਬੇਡਿੰਗ ਟਾਲੋ।

ਆਮ JWT ਸੁਰੱਖਿਆ ਗਲਤੀਆਂ ਜਿਨ੍ਹਾਂ ਤੋਂ ਬਚਣਾ ਚਾਹੀਦਾ ਹੈ

JWT ਆਸਾਨ ਹਨ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਇਨਸੀਡੈਂਟ ਪ੍ਰਿਡਿਕਟੇਬਲ ਗਲਤੀਆਂ ਤੋਂ ਹੁੰਦੇ ਹਨ। ਇੱਕ JWT ਨੂੰ ਨੋਟਾਂ ਵਾਂਗ ਸੋਚੋ: ਜਿਸਨੇ ਵੀ ਇਸਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਲਿਆ ਉਹ ਅਕਸਰ ਇਸਨੂੰ ਖਰਚ ਵੀ ਕਰ ਸਕਦਾ ਹੈ।

1) ਬਹੁਤ ਲੰਬੀਆਂ ਮਿਆਦਾਂ

ਜੇ ਟੋਕਨ ਕਈ ਦਿਨ ਜਾਂ ਹਫਤੇ ਵਾਸਤੇ ਰਿਹਾ, ਤਾਂ ਲੀਕ ਹੋਣ 'ਤੇ ਹਮਲਾਵਰ ਨੂੰ ਉਹ ਬਾਰਾ ਵਿੰਡੋ ਮਿਲ ਜਾਂਦੀ ਹੈ।

ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨ (ਕਈ ਮਿੰਟ) ਪਸੰਦ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਸੁਰੱਖਿਅਤ ਮਕੈਨਿਜ਼ਮ ਰਾਹੀਂ ਰੀਫ੍ਰੈਸ਼ ਕਰੋ। ਜੇ "ਮੈਨੇ ਰਿਮੈਮਬਰ ਮੀ" ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਹ ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨਾਂ ਅਤੇ ਸਰਵਰ-ਪਾਸੇ ਨਿਯੰਤਰਨਾਂ ਨਾਲ ਕਰੋ।

2) issuer ਅਤੇ audience ਚੈੱਕ ਛੱਡਣਾ

ਸੱਚਾ ਸਿਗਨੇਚਰ ਹੀ ਕਾਫੀ ਨਹੀਂ। iss ਅਤੇ aud ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਸਮੇਂ-ਆਧਾਰਿਤ claims ਜਿਵੇਂ exp ਅਤੇ nbf ਨੂੰ ਵੈਲਿਡੇਟ ਕਰੋ।

3) ਦੇਕੋਡ ਕੀਤੇ ਪੇਲੋਡ 'ਤੇ ਵਿਸ਼ਵਾਸ ਕਰਨਾ

ਡੇਕੋਡਿੰਗ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨਹੀਂ ਹੈ। ਹਮੇਸ਼ਾ ਸਰਵਰ 'ਤੇ ਸਿਗਨੇਚਰ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਅਧਿਕਾਰ ਸਰਵਰ-ਪਾਸੇ ਲਾਗੂ ਕਰੋ।

4) ਅਲਗੋਰਿਦਮ ਕਰਪਲੈਕਸੀਟੀ ਅਤੇ ਕੀ ਮਿਕਅੱਪ

• ਟੋਕਨ ਦੇਖਾਉਂਦੇ alg ਨੂੰ ਸਹੀ ਸਮਝ ਕੇ ਹੀ ਸਵੀਕਾਰੋ। allowlist ਰੱਖੋ।
• ਸਮਮਿਤ੍ਰਿਕ ਕਿ (HS256) ਅਤੇ ਪਬਲਿਕ/ਪ੍ਰਾਈਵੇਟ ਕਿ (RS256/ES256) ਨੂੰ ਮਿਸ-ਕਨਫ਼ਿਗਰ ਨਾ ਕਰੋ।
• ਪਰਿਬਾਰਧ ਦਾ ਪ੍ਰਭਾਵ ਘਟਾਉਣ ਲਈ ਹਰ ਪਰਿਵੇਸ਼ ਲਈ ਕੁੰਜੀਆਂ ਵੱਖ-ਵੱਖ ਰੱਖੋ ਅਤੇ ਰੋਟੇਸ਼ਨ ਕਰੋ।

5) URL, ਲੌਗਾਂ ਅਤੇ ਰੈਫਰਰਜ਼ ਰਾਹੀਂ ਟੋਕਨ ਲੀਕੇਜ

JWTs ਨੂੰ ਕੁਇਰੀ ਪੈਰਾਮਜ਼ ਵਿੱਚ ਨਾ ਰੱਖੋ। ਉਹ ਬਰਾਊਜ਼ਰ ਇਤਿਹਾਸ, ਸਰਵਰ ਲਾਗ, ਐਨਲਿਟਿਕਸ ਟੂਲ ਅਤੇ ਰੈਫਰਰ ਹੈਡਰਾਂ ਵਿੱਚ ਆ ਸਕਦੇ ਹਨ।

ਇਸਦੀ ਥਾਂ Authorization: Bearer ... ਵਰਤੋ।

6) ਕੀ ਰੋਟੇਸ਼ਨ ਜਾਂ ਰਿਵੋਕੇਸ਼ਨ ਯੋਜਨਾ ਨਾ ਹੋਣਾ

ਮੰਨੋ ਕਿ ਕੁੰਜੀਆਂ ਅਤੇ ਟੋਕਨ ਲੀਕ ਹੋ ਸਕਦੇ ਹਨ। ਸਾਈਨਿੰਗ ਕੀਜ਼ ਰੋਟੇ ਕਰੋ, kid ਵਰਤਕੇ ਨਰਮ ਰੋਟੇਸ਼ਨ ਸਹਾਇਤ ਕਰੋ, ਅਤੇ ਇੱਕ ਰਿਵੋਕੇਸ਼ਨ ਯੋਜਨਾ (ਛੋਟੀ ਮਿਆਦ + ਖਾਤਾ/ਸੈਸ਼ਨ ਡਿਸੇਬਲ ਕਰਨ di ਸਮਰੱਥਾ) ਰੱਖੋ। ਸਟੋਰੇਜ ਗਾਈਡੈਂਸ ਲਈ ਦੇਖੋ /blog/where-to-store-jwts-safely।

JWT ਕਦੋਂ ਵਰਤਣਾ (ਅਤੇ ਕਦੋਂ ਨਹੀਂ)

JWT ਲਾਭਕਾਰੀ ਹਨ, ਪਰ ਇਹ ਹਰ ਹਾਲਤ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਨਹੀਂ ਹੁੰਦੇ। ਅਸਲ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕੀ ਤੁਸੀਂ ਇੱਕ self-contained ਟੋਕਨ ਤੋਂ ਫਾਇਦਾ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਹਰ ਰਿਕਵੇਸਟ 'ਤੇ ਬਿਨਾਂ ਡੇਟਾਬੇਸ ਲੁੱਕਅੱਪ ਤੋਂ ਵੈਰੀਫਾਈ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

JWT ਲਈ ਚੰਗੇ ਫਿੱਟ

• ਸਕੇਲ 'ਤੇ ਸਟੇਟਲੈਸ APIs: ਲੋਕਲ ਵੈਰੀਫਿਕੇਸ਼ਨ (ਸਿਗਨੇਚਰ + expiry) ਬਿਨਾਂ ਪ੍ਰਤੀ-ਰਿਕਵੇਸਟ ਸੈਸ਼ਨ ਲੁੱਕਅੱਪ
• ਕਈ ਸੇਵਾਵਾਂ / ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼: ਸਾਂਝੇ ਵੈਰੀਫਿਕੇਸ਼ਨ ਨਿਯਮ ਅਤੇ ਪਬਲਿਕ ਕੀਜ਼
• SPAs ਅਤੇ ਮੋਬਾਈਲ ਐਪਸ: ਕਲਾਇੰਟ ਸਿੱਧਾ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ
• ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨ: ਚੋਰੀ ਦਾ ਪ੍ਰਭਾਵ ਘੱਟ

ਜਦੋਂ JWT ਠੀਕ ਨਹੀਂ ਨਿਕਲਦੇ

• ਤੁਰੰਤ ਰਿਵੋਕੇਸ਼ਨ ਲਾਜ਼ਮੀ ਹੋਵੇ: ਜੇ ਤੁਹਾਨੂੰ "ਹੁਣੇ ਸਾਰੇ ਲਾਗ ਆਊਟ" ਦੀ ਲੋੜ ਹੈ ਤਾਂ ਸੈਸ਼ਨ ਆਸਾਨ ਰਹਿੰਦਾ ਹੈ
• ਤੁਹਾਨੂੰ ਸੰਵੇਦਨਸ਼ੀਲ ਡਾਟਾ ਟੋਕਨ ਵਿੱਚ ਲੈ ਜਾਣੀ ਪਏ: ਆਮ JWTs ਸਾਈਨ ਕੀਤੇ ਹੁੰਦੇ ਹਨ, ਇਨਕ੍ਰਿਪਟਡ ਨਹੀਂ
• ਲੰਬੀ ਮਿਆਦ ਵਾਲੇ ਟੋਕਨ: ਇਹ ਉੱਚ-ਮੁੱਲ ਵਾਲੇ ਹੁੰਦੇ ਹਨ ਅਤੇ ਚੋਰਦੇ ਲਾਇਕ ਹੁੰਦੇ ਹਨ

ਜਦੋਂ ਸਧਾਰਨ ਸੈਸ਼ਨ ਕੁਕੀ ਬਿਹਤਰ ਹੁੰਦੇ ਹਨ

ਪਾਰੰਪਰਿਕ ਸਰਵਰ-ਰੈਂਡਰ ਕੀਤੇ ਵੈੱਬ ਐਪਾਂ ਲਈ ਜਿਥੇ ਸਿੱਧੇ ਅਮਲ ਨਾਲ ਇਨਵੈਲਿਡੇਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਸਰਵਰ-ਸਾਈਡ ਸੈਸ਼ਨਸ ਨੂੰ HttpOnly ਕੁਕੀਆਂ ਨਾਲ ਅਕਸਰ ਸਧਾਰਨ ਅਤੇ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਹੁੰਦਾ ਹੈ।

ਫੈਸਲਾ ਕਰਨ ਲਈ ਤੇਜ਼ ਚੈੱਕਲਿਸਟ

ਜੇ ਤੁਹਾਨੂੰ ਸਟੇਟਲੈਸ ਵੈਰੀਫਿਕੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਤੁਸੀਂ ਟੋਕਨਾਂ ਨੂੰ ਛੋਟੀ ਮਿਆਦ ਰੱਖ ਸਕਦੇ ਹੋ, ਤਾਂ JWT ਚੁਣੋ।

ਟਾਲੋ JWT ਜਦੋਂ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਰਿਵੋਕੇਸ਼ਨ ਚਾਹੀਦੀ ਹੋਵੇ, ਤੁਸੀਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਟੋਕਨ ਵਿੱਚ ਰੱਖ ਰਹੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਬਿਨਾਂ ਕਿਸੇ ਰੁਕਾਵਟ ਦੇ ਸੈਸ਼ਨ ਕੁਕੀ ਵਰਤ ਸਕਦੇ ਹੋ।

ਪ੍ਰੈਕਟੀਕਲ ਚੈਕਲਿਸਟ ਅਤੇ FAQs

ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈਕਲਿਸਟ (ਹਰ ਵਾਰੀ ਕੀ ਜਾਂਚੋ)

1. ਸਿਗਨੇਚਰ ਯਥਾਰਥ ਹੈ

ਸਹੀ ਕੀ ਅਤੇ ਉਮੀਦ ਕੀਤੀ ਅਲਗੋਰਿਦਮ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰੋ। ਗਲਤ ਸਿਗਨੇਚਰ ਨੂੰ ਰੱਦ ਕਰੋ—ਕੋਈ ਛੂਟ ਨਹੀਂ।

2. exp (ਮਿਆਦ)

ਪੱਕਾ ਕਰੋ ਕਿ ਟੋਕਨ ਦੀ ਮਿਆਦ ਖਤਮ ਨਹੀਂ ਹੋਈ।

3. nbf (not before)

ਜੇ ਮੌਜੂਦ ਹੋਵੇ ਤਾਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਟੋਕਨ ਬਚੋਂ ਪਹਿਲਾਂ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਰਿਹਾ।

4. aud (audience)

ਪੱਖ ਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ ਟੋਕਨ ਤੁਹਾਡੇ API/ਸੇਵਾ ਲਈ ਹੀ ਬਣਾਇਆ ਗਿਆ ਹੈ।

5. iss (issuer)

ਪੱਕਾ ਕਰੋ ਕਿ ਟੋਕਨ ਉਮੀਦ ਕੀਤੇ issuer ਵੱਲੋਂ ਆਇਆ ਹੈ।

6. ਸੈਨਿਟੀ ਚੈਕ (ਸਿਫਾਰਸ਼ੀ)

ਟੋਕਨ ਫਾਰਮੈਟ ਵੈਧ ਕਰੋ, ਅਧਿਕਤਮ ਆਕਾਰ ਲਗਾਓ, ਅਤੇ ਅਚਾਨਕ claim ਕਿਸਮਾਂ ਨੂੰ ਰੱਦ ਕਰੋ ਤਾਂ ਜੋ ਐਜ-ਕੇਸ ਬੱਗ ਘਟ ਸਕਣ।

HS256 vs RS256/ES256 ਚੁਣਣ ਦਾ ਤਰੀਕਾ

• HS256 (symmetric key): ਇੱਕ ਸਾਂਝਾ ਸੇਕ੍ਰੇਟ ਨਾਲ ਸਾਈਨ ਅਤੇ ਵੈਰੀਫਾਈ ਹੁੰਦਾ ਹੈ。

  • ਚੰਗਾ: ਇਕੱਲੀ ਐਪ/API ਲਈ ਜਿਹੜਾ ਇੱਕ ਟੀਮ ਦੇ ਕੰਟਰੋਲ ਹੇਠ ਹੈ।
  • ਧਿਆਨ ਰੱਖੋ: ਜੇ ਕੋਈ ਵੀ ਵੈਰੀਫਾਇਰ ਸੇਕ੍ਰੇਟ ਰੱਖਦਾ ਹੈ ਤਾਂ ਉਹ ਵੀ ਟੋਕਨ ਬਣਾਉਣ ਯੋਗ ਹੋ ਜਾਵੇਗਾ。

• RS256 / ES256 (asymmetric keys): ਪ੍ਰਾਈਵੇਟ ਕੀ ਸਾਈਨ ਕਰਦੀ ਹੈ; ਪਬਲਿਕ ਕੀ ਵੈਰੀਫਾਈ ਕਰਦੀ ਹੈ。

  • ਚੰਗਾ: ਵੱਧ ਸੇਵਾਵਾਂ ਨੂੰ ਟੋਕਨ ਵਰਤਦੇ ਹੋਣ 'ਤੇ, ਜਿੱਥੇ ਤੁਸੀਂ ਪਬਲਿਕ ਕੀ ਵੰਡ ਸਕਦੇ ਹੋ ਬਿਨਾਂ ਸਾਈਨਿੰਗ ਸਮਰੱਥਾ ਦਿੱਤੇ।
  • ਓਪਰੇਸ਼ਨਲ ਨੋਟ: ਰੋਟੇਸ਼ਨ ਅਕਸਰ ਸੁਰੱਖਿਅਤ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਸਿਰਫ਼ ਸਾਈਨਰ ਕੋਲ ਪ੍ਰਾਈਵੇਟ ਕੀ ਹੁੰਦੀ ਹੈ।

ਨਿਯਮ: ਜੇ ਇੱਕ ਤੋਂ ਵੱਧ ਸੁਤੰਤਰ ਸਿਸਟਮਾਂ ਨੂੰ ਟੋਕਨ ਵੈਰੀਫਾਈ ਕਰਨ ਦੀ ਲੋੜ ਹੈ (ਜਾਂ ਤੁਸੀਂ ਹਰ ਵੈਰੀਫਾਇਰ 'ਤੇ ਪੂਰਾ ਭਰੋਸਾ ਨਹੀਂ ਕਰਦੇ), ਤਾਂ RS256/ES256 ਨੂੰ ਤਰਜੀਹ ਦਿਓ।

ਮਾਨੀਟਰੀੰਗ ਅਤੇ ਲੌਗਿੰਗ (ਟੋਕਨ ਲੀਕ ਕੀਤੇ ਬਿਨਾਂ)

• ਕੱਚੇ ਟੋਕਨਾਂ ਨੂੰ ਲੌਗ ਨਾ ਕਰੋ (ਹੈਡਰ, ਕੁਕੀਆਂ, ਕੁਇਰੀ ਸਟਰਿੰਗ)।
• ਜੇ ਤੁਸੀਂ correlation ਲਈ ਲੌਗ ਕਰਨੀ ਹੈ, ਤਾਂ ਟੋਕਨ ਫਿੰਗਰਪ੍ਰਿੰਟ (ਉਦਾਹਰਨ ਲਈ ਇੱਕ ਹੈਸ਼) ਜਾਂ ਸੁਰੱਖਿਅਤ ਮੈਟਾ ਡੇਟਾ (iss, aud, ਅਤੇ ਨੀਤੀ ਮਨਜ਼ੂਰ ਹੋਏ ਤਾਂ ਯੂਜ਼ਰ ID) ਲੌਗ ਕਰੋ।
• ਅਨੋਮਲੀਜ਼ ਲਈ ਨਿਗਰਾਨੀ ਕਰੋ: ਸਿਗਨੇਚਰ ਫੇਲ, expired ਟੋਕਨਾਂ ਵਿੱਚ spike, ਅਜੀਬ audience/issuer, ਅਤੇ ਸ਼ੱਕੀ ਰੀਫ੍ਰੈਸ਼ ਪੈਟਰਨ।

FAQs

ਕੀ JWT ਇੰਕ੍ਰਿਪਟਡ ਹੈ?

ਮੂਲ ਰੂਪ ਵਿੱਚ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ JWTs ਸਾਈਂ ਕੀਤੇ ਹੁੰਦੇ ਹਨ, ਇਨਕ੍ਰਿਪਟਡ ਨਹੀਂ।

• ਸਾਈਨਿੰਗ ਇੰਟੀਗ੍ਰਿਟੀ ਦਿਖਾਉਂਦੀ ਹੈ ਅਤੇ ਭਰੋਸੇਯੋਗ ਸਾਈਨਰ ਦੀ ਪਛਾਣ ਕਰਦੀ ਹੈ।
• ਕੋਈ ਵੀ ਜੋ ਟੋਕਨ ਹਾਸਲ ਕਰ ਲੈਂਦਾ ਹੈ ਉਹ ਹੈਡਰ ਅਤੇ ਪੇਲੋਡ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ।

ਜੇ ਗੁਪਤਤਾ ਚਾਹੀਦੀ ਹੈ ਤਾਂ JWE ਜਾਂ JWT ਵਿੱਚੋਂ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਨੂੰ ਬਾਹਰ ਰੱਖੋ।

ਕੀ ਮੈਂ JWT ਰੱਦ ਕਰ ਸਕਦਾ/ਸਕਦੀ ਹਾਂ?

ਜੇ ਤੁਸੀਂ ਕੇਵਲ self-contained access tokens 'ਤੇ ਨਿਰਭਰ ਹੋ, ਤਾਂ ਇਹ ਅਸਾਨ ਨਹੀਂ। ਆਮ ਅਪ੍ਰੋਚਾਂ ਵਿੱਚ ਛੋਟੀ ਮਿਆਦ ਵਾਲੇ access ਟੋਕਨ, high-risk ਘਟਨਾਵਾਂ ਲਈ deny-lists, ਜਾਂ ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨ ਰੋਟੇਸ਼ਨ ਸ਼ਾਮਿਲ ਹਨ।

exp ਕਿੰਨੀ ਲੰਬੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?

ਜਿੰਨੀ ਛੋਟੀ ਹੋ ਸਕੇ ਉਤਨੀ ਛੋਟੀ—ਤੁਹਾਡੀ UX ਅਤੇ ਆਰਕੀਟੈਕਚਰ ਦੀ ਇਜਾਜ਼ਤ ਮਦਦਗਾਰ ਹੈ। ਕਈ APIs access ਟੋਕਨਾਂ ਲਈ ਮਿੰਟ ਵਰਤਦੇ ਹਨ ਅਤੇ ਲੰਬੇ ਸੈਸ਼ਨ ਲਈ ਰੀਫ੍ਰੈਸ਼ ਟੋਕਨ ਵਰਤਦੇ ਹਨ।

Koder.ai ਨਾਲ JWT-ਸੁਰੱਖਿਅਤ ਐਪ ਤੇਜ਼ ਬਣਾਉਣਾ

ਜੇ ਤੁਸੀਂ ਨਵੇਂ API ਜਾਂ SPA ਵਿੱਚ JWT ਅਥੇਨ ਲਾਗੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਬਹੁਤ ਸਾਰਾ ਕੰਮ ਦੁਹਰਾਉਣਯੋਗ ਹੁੰਦਾ ਹੈ: ਮਿਡਲਵੇਅਰ ਵਾਇਰਿੰਗ, iss/aud/exp ਦੀ ਜਾਂਚ, ਕੁਕੀ ਫਲੈਗ ਸੈਟ ਕਰਨਾ, ਅਤੇ ਲੌਗਾਂ ਤੋਂ ਟੋਕਨ ਹਟਾਉਣਾ।

Koder.ai ਨਾਲ, ਤੁਸੀਂ ਗੱਲ-ਬਾਤ-ਚਲਾਉਣ ਵਾਲੇ ਵਰਕਫਲੋ ਰਾਹੀਂ ਇੱਕ ਵੈੱਬ ਐਪ (React), ਬੈਕਐਂਡ ਸੇਵਾਵਾਂ (Go + PostgreSQL), ਜਾਂ ਇੱਕ Flutter ਮੋਬਾਈਲ ਐਪ ਤੇ ਜੀ-ਕੋਡ ਤਿਆਰ ਕਰ ਸਕਦੇ ਹੋ—ਫਿਰ planning mode ਵਿੱਚ ਸੁਰੱਖਿਆ ਨੀਤੀਆਂ ਬਨਾਓ, snapshots ਅਤੇ rollback ਵਰਤੋ, ਅਤੇ ਜਦੋਂ ਤਿਆਰ ਹੋਵੋ ਤਾਂ ਸਰੋਤ ਕੋਡ ਨਿਰਯਾਤ ਕਰੋ। ਇਹ JWT-ਆਧਾਰਿਤ ਅਥੇਨ ਫਲੋਜ਼ ਬਣਾਉਣ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਾਜਿਕ, ਕੀ ਰੋਟੇਸ਼ਨ ਰਣਨੀਤੀ ਅਤੇ ਡਿਪਲੋਇਮੈਂਟ ਸੈਟਿੰਗਜ਼ 'ਤੇ ਕੰਟਰੋਲ ਦੇਂਦਾ ਹੈ।