19 ਅਪ੍ਰੈ 2025·8 ਮਿੰਟ
ਕਿਵੇਂ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ संभਾਲਦੇ ਹਨ
ਸਿੱਖੋ ਕਿ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੇ ਹਨ: ਸੈਸ਼ਨ, ਟੋਕਨ, OAuth/OIDC, middleware, ਰੋਲ, ਪਾਲਿਸੀਆਂ ਅਤੇ ਮੁੱਖ ਸੁਰੱਖਿਆ ਖਤਰੇ।
ਸਿੱਖੋ ਕਿ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਦੇ ਹਨ: ਸੈਸ਼ਨ, ਟੋਕਨ, OAuth/OIDC, middleware, ਰੋਲ, ਪਾਲਿਸੀਆਂ ਅਤੇ ਮੁੱਖ ਸੁਰੱਖਿਆ ਖਤਰੇ।
ਪ੍ਰਮਾਣਿਕਤਾ ਪੁੱਛਦੀ ਹੈ “ਤੁਸੀਂ ਕੌਣ ਹੋ?” ਅਤੇ ਅਧਿਕਾਰ ਪੁੱਛਦਾ ਹੈ “ਤੁਹਾਨੂੰ ਕੀ ਕਰਨ ਦੀ ਆਗਿਆ ਹੈ?” ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਇਹਨਾਂ ਨੂੰ ਸੰਬੰਧਿਤ ਪਰ ਵੱਖ-ਵੱਖ ਮਸਲੇ ਸਮਝਦੇ ਹਨ — ਇਹ ਵੱਖਰਾ ਢਾਂਚਾ ਹੀ ਐਪ ਵਧਣ ਦੇ ਨਾਲ ਸੁਰੱਖਿਆ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਮਕਸਦ ਇਹ ਪਾਵਣਾ ਹੈ ਕਿ ਇੱਕ ਯੂਜ਼ਰ (ਜਾਂ ਸਰਵਿਸ) ਉਹੀ ਹੈ ਜੋ ਉਹ ਦਾਅਵਾ ਕਰ ਰਿਹਾ ਹੈ। ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਹੀ ਤਰੀਕੇ ਨੂੰ ਹਾਰਡ-ਕੋਡ ਨਹੀਂ ਕਰਦੇ; ਉਹ ਪਾਸਵਰਡ ਲੌਗਿਨ, ਸੋਸ਼ਲ ਲੌਗਿਨ, SSO, API ਕੀਜ਼, ਅਤੇ ਸਰਵਿਸ ਕਰਿਡੈਂਸ਼ਲ ਵਰਗੀਆਂ ਆਮ ਵਿਕਲਪਾਂ ਲਈ ਇੱਕਸਟੇਂਸ਼ਨ ਪ้อยੰਟ ਦਿੰਦੇ ਹਨ।
ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਨਤੀਜਾ ਇੱਕ ਪਹਿਚਾਣ ਹੁੰਦੀ ਹੈ: ਯੂਜ਼ਰ ID, ਅਕਾਉਂਟ ਸਥਿਤੀ, ਅਤੇ ਕਈ ਵਾਰੀ ਕੁਝ ਮੁੱਢਲੇ ਗੁਣ (ਜਿਵੇਂ ਈਮੇਲ ਵੈਰੀਫਾਈ ਹੋਈ ਹੈ ਜਾਂ ਨਹੀਂ)। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਇਹ ਫੈਸਲਾ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕਿਸ ਐਕਸ਼ਨ ਦੀ ਆਗਿਆ ਹੈ — ਸਿਰਫ਼ ਇਹ ਦੱਸਦੀ ਹੈ ਕਿ ਰਿਕੁਐਸਟ ਕਿਸ ਨੇ ਕੀਤੀ ਹੈ।
ਅਧਿਕਾਰ ਸਥਾਪਤ ਪਹਿਚਾਣ ਅਤੇ ਰਿਕੁਐਸਟ ਸੰਦਰਭ (ਰੂਟ, ਰਿਸੋਰਸ ਮਾਲਿਕ, ਟੈਨੈਂਟ, ਸਕੋਪ, ਵਾਤਾਵਰਣ ਆਦਿ) ਦਾ ਉਪਯੋਗ ਕਰਦੇ ਹੋਏ ਨਿਰਣਾਇਕ ਕਰਦਾ ਹੈ ਕਿ ਕੋਈ ਐਕਸ਼ਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇੱਥੇ ਰੋਲ, ਪਰਮੀਸ਼ਨ, ਪਾਲਿਸੀਆਂ ਅਤੇ ਰਿਸੋਰਸ-ਆਧਾਰਿਤ ਨਿਯਮ ਆਉਂਦੇ ਹਨ।
ਫਰੇਮਵਰਕ ਅਕਸਰ ਅਧਿਕਾਰ ਨਿਯਮਾਂ ਨੂੰ ਪ੍ਰਮਾਣਿਕਤਾ ਤੋਂ ਵੱਖ ਰੱਖਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀ:
ਜ਼ਿਆਦਾਤਰ ਫਰੇਮਵਰਕ ਰਿਕੁਐਸਟ ਲਾਈਫਸਾਇਕਲ ਵਿੱਚ ਕੇਂਦਰੀ ਬਿੰਦੂਆਂ ਰਾਹੀਂ ਨਿਯਮ ਲਾਗੂ ਕਰਦੇ ਹਨ:
ਭਾਵੇਂ ਨਾਮ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ, ਨਿਰਮਾਣ ਬਲਾਕ ਸਾਧਾਰਨ ਹੀ ਰਹਿੰਦੇ ਹਨ: ਇੱਕ identity store (ਯੂਜ਼ਰ ਅਤੇ ਕਰਿਡੈਂਸ਼ਲ), ਇੱਕ session ਜਾਂ token ਜੋ ਰਿਕੁਐਸਟਾਂ ਵਿੱਚ ਪਹਿਚਾਣ ਲੈ ਕੇ ਜਾਂਦਾ ਹੈ, ਅਤੇ middleware/guards ਜੋ ਇੱਕਸਾਰ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਲਾਗੂ ਕਰਦੇ ਹਨ।
ਇਸ ਲੇਖ ਦੇ ਉਦਾਹਰਣ ਰੂਪਕ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਆਪਣੇ ਚੁਣੇ ਹੋਏ ਫਰੇਮਵਰਕ ਨਾਲ ਮੈਪ ਕਰ ਸਕੋ।
ਫਰੇਮਵਰਕ “ਕਿਸੇ ਨੂੰ ਲੌਗਿਨ” ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੁੱਧ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਪਹਿਚਾਣ ਡੇਟਾ ਲੱਭਣ ਲਈ ਇੱਕ ਜਗ੍ਹਾ (identity store) ਅਤੇ ਕੋਡ ਵਿੱਚ ਉਸ ਪਹਿਚਾਣ ਦੀ ਇੱਕ ਸਥਿਰ ਪ੍ਰਤਿਨਿਧਤਾ (user model)। ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਬਹੁਤ ਵਾਰੀ ਇਨ੍ਹਾਂ ਦੋਹਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਐਬਸਟਰੈਕਸ਼ਨ ਦਿੰਦੇ ਹਨ।
ਫਰੇਮਵਰਕ ਅਕਸਰ ਕਈ ਬੈਕਐਂਡਸ ਨੂੰ ਸਮਰਥਨ ਦਿੰਦੇ ਹਨ, ਜਾਂ ਤਿਆਰ-ਬਣੇ ਪਲੱਗਇਨ ਰਾਹੀਂ:
ਮੁੱਖ ਫਰਕ ਇਹ ਹੈ ਕਿ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਕੌਣ ਹੈ। ਡੇਟਾਬੇਸ ਯੂਜ਼ਰਾਂ ਕੋਲ ਹੋਣ 'ਤੇ ਤੁਹਾਡਾ ਐਪ ਕਰਿਡੈਂਸ਼ਲ ਅਤੇ ਪ੍ਰੋਫਾਈਲ ਡੇਟਾ ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ। IdP ਜਾਂ ਡਾਇਰੈਕਟਰੀ ਨਾਲ, ਤੁਹਾਡਾ ਐਪ ਅਕਸਰ ਇੱਕ "ਲੋਕਲ ਸ਼ੈਡੋ ਯੂਜ਼ਰ" ਰੱਖਦਾ ਹੈ ਜੋ ਬਾਹਰੀ ਪਹਿਚਾਣ ਨਾਲ ਲਿੰਕ ਕਰਦਾ ਹੈ।
ਚਾਹੇ ਫਰੇਮਵਰਕ ਇੱਕ ਡਿਫਾਲਟ ਯੂਜ਼ਰ ਮਾਡਲ ਬਣਾਉਂਦੇ ਹੋਣ, ਪਰ ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਫੀਲਡ ਇੱਕਸਾਰ ਰੱਖਦੀਆਂ ਹਨ:
is_verified, is_active, is_locked, deleted_at。ਇਹ ਫਲੈਗ ਮਹੱਤਵਪੂਰਨ ਹਨ ਕਿਉਂਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਸਿਰਫ਼ "ਸਹੀ ਪਾਸਵਰਡ?" ਹੀ ਨਹੀਂ—ਇਹ ਵੀ ਪਹੁੰਚਦੀ ਹੈ ਕਿ "ਕੀ ਇਹ ਅਕਾਉਂਟ ਇਸ ਵੇਲੇ ਸਾਈਨ-ਇਨ ਕਰਨ ਲਈ ਆਗਿਆਵਾਨ ਹੈ?"
ਇੱਕ ਪ੍ਰਯੋਗਿਕ identity store ਆਮ ਲਾਈਫਸਾਇਕਲ ਘਟਨਾਵਾਂ ਦਾ ਸਹਾਰਾ ਦਿੰਦਾ ਹੈ: ਰਜਿਸਟਰੇਸ਼ਨ, ਈਮੇਲ/ਫ਼ੋਨ ਵੈਰੀਫਿਕੇਸ਼ਨ, ਪਾਸਵਰਡ ਰੀਸੈੱਟ, ਸੰਵੇਦਨਸ਼ੀਲ ਬਦਲਾਵਾਂ ਤੋਂ ਬਾਅਦ ਸੈਸ਼ਨ ਰੱਦ ਕਰਨਾ, ਅਤੇ ਨਿਸ਼ਕ੍ਰਿਆ ਕਰਨਾ ਜਾਂ ਸੋਫਟ-ਡਿਲੀਟ। ਫਰੇਮਵਰਕ ਅਕਸਰ ਪ੍ਰਿਮਿਟਿਵਜ਼ (ਟੋਕਨ, ਟਾਈਮਸਟੈਂਪ, ਹੁੱਕ) ਦਿੰਦੇ ਹਨ, ਪਰ ਤੁਸੀਂ ਨਿਯਮ ਪਰਿਭਾਸ਼ਤ ਕਰਦੇ ਹੋ: ਮਿਆਦਾਂ, ਰੇਟ ਲਿਮਿਟਸ, ਅਤੇ ਇੱਕ ਅਕਾਉਂਟ ਡਿਸੇਬਲ ਹੋਣ 'ਤੇ ਮੌਜੂਦਾ ਸੈਸ਼ਨਾਂ ਨਾਲ ਕੀ ਹੁੰਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ user providers, adapters, ਜਾਂ repositories ਵਰਗੇ ਇੱਕਸਟੇਂਸ਼ਨ ਪਾਇੰਟ ਦਿੰਦੇ ਹਨ। ਇਹ ਕੰਪੋਨੈਂਟ ਇਹ ਤਰਜਮਾ ਕਰਦੇ ਹਨ: “ਇੱਕ ਲੌਗਿਨ ਆਈਡੈਂਟੀਫਾਇਰ ਦਿੱਤੇ ਜਾਣ 'ਤੇ ਯੂਜ਼ਰ ਲੱਭੋ” ਅਤੇ “ਇੱਕ ਯੂਜ਼ਰ ID ਦਿੱਤਾ ਗਿਆ ਹੈ ਤਾਂ ਮੌਜੂਦਾ ਯੂਜ਼ਰ ਲੋਡ ਕਰੋ”—ਚਾਹੇ ਇਹ SQL ਕਵੈਰੀ ਹੋਵੇ, IdP ਨੂੰ ਕਾਲ, ਜਾਂ enterprise ਡਾਇਰੈਕਟਰੀ ਲੁੱਕਅਪ।
Session-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਕਈ ਸਰਵਰ-ਰੇਂਡਰ ਕੀਤੀਆਂ ਐਪਸ ਲਈ "ਕਲਾਸਿਕ" ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਹੈ। ਵਿਚਾਰ ਸਧਾਰਨ ਹੈ: ਸਰਵਰ ਯਾਦ ਰੱਖਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੌਣ ਹੋ, ਅਤੇ ਬਰਾਊਜ਼ਰ ਉਸ ਯਾਦ ਦਾ ਇੱਕ ਛੋਟਾ ਪੁਆਇੰਟਰ ਰੱਖਦਾ ਹੈ।
ਸਫਲ ਲੌਗਿਨ ਤੋਂ ਬਾਅਦ, ਫਰੇਮਵਰਕ ਇੱਕ ਸਰਵਰ-ਸਾਈਡ ਸੈਸ਼ਨ ਰਿਕਾਰਡ ਬਣਾਉਂਦਾ (ਅਕਸਰ ਇੱਕ ਰੈਂਡਮ session ID ਜੋ ਯੂਜ਼ਰ ਨਾਲ ਮੈਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ)। ਬਰਾਊਜ਼ਰ ਨੂੰ ਉਹ session ID ਵਾਲੀ ਕੁਕੀ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਹਰ ਬਾਰ ਦੀ ਰਿਕੁਐਸਟ 'ਤੇ ਬਰਾਊਜ਼ਰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਕੁਕੀ ਵਾਪਸ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਉਸਨੂੰ ਵਰਤ ਕੇ ਲੌਗਡ-ਇਨ ਯੂਜ਼ਰ ਲੱਭਦਾ ਹੈ।
ਕੁਕੀ ਸਿਰਫ਼ ਇੱਕ ਪਹਿਚਾਣਕਰਤਾ ਹੈ (ਖੁਦ ਯੂਜ਼ਰ ਡੇਟਾ ਨਹੀਂ), ਇਸ ਲਈ ਸੰਵੇਦਨਸ਼ੀਲ ਜਾਣਕਾਰੀ ਸਰਵਰ 'ਤੇ ਰਹਿੰਦੀ ਹੈ।
ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਸੈਸ਼ਨ ਕੁਕੀਜ਼ ਨੂੰ ਚੋਰੀ ਜਾਂ ਗਲਤ-ਉਪਯੋਗ ਤੋਂ ਮੁਸ਼ਕਲ ਬਣਾਉਣ ਲਈ ਸੁਰੱਖਿਆ ਦੇ ਡਿਫਾਲਟ ਸੈਟ ਕਰਦੇ ਹਨ:
ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸੈਟਿੰਗਾਂ “session cookie settings” ਜਾਂ “security headers” ਹੇਠਾਂ ਦੇਖੋਗੇ।
ਫਰੇਮਵਰਕ ਅਕਸਰ ਤੁਸੀਂ ਚੁਣ ਸਕਣਗੇ:
ਉੱਚ-ਸਤਹ 'ਤੇ, ਟਰੇਡ-ਆਫ਼ ਸਪੀਡ, ਟਿਕਾਊਪਨ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਵਿਚਕਾਰ ਹੈ।
ਲੌਗਆਉਟ ਦੇ ਦੋ ਮਤਲਬ ਹੋ ਸਕਦੇ ਹਨ:
ਫਰੇਮਵਰਕ ਅਕਸਰ “ਲੌਗਆਉਟ ਹਰ ਥਾਂ” ਲਈ ਯੂਜ਼ਰ "session version" ਟਰੈਕ ਕਰਦੇ ਹਨ, ਕਈ session IDs ਰੱਖਦੇ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਰਿਵੋਕ ਕਰਦੇ ਹਨ। ਜੇ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਰਿਵੋਕੇਸ਼ਨ ਚਾਹੀਦੀ ਹੈ, ਤਾਂ session-ਆਧਾਰਿਤ auth ਅਕਸਰ ਟੋਕਨ-ਆਧਾਰਿਤ ਦੀ ਤੁਲਨਾ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਸਰਵਰ ਤੁਰੰਤ ਇੱਕ ਸੈਸ਼ਨ ਭੁੱਲ ਸਕਦਾ ਹੈ।
ਟੋਕਨ-ਆਧਾਰਿਤ ਪ੍ਰਮਾਣਿਕਤਾ ਸਰਵਰ-ਸਾਈਡ ਸੈਸ਼ਨ ਲੁੱਕਅੱਪ ਨੂੰ ਇੱਕ ਸਟਰਿੰਗ ਨਾਲ ਬਦਲ ਦਿੰਦੀ ਹੈ ਜੋ ਕਲਾਇੰਟ ਹਰ ਰਿਕੁਐਸਟ 'ਤੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਟੋਕਨ ਇਸ ਪੈਟਰਨ ਨੂੰ ਪਹਿਲ-ਕਤਾਰ ਦੇ ਰੂਪ ਵਿੱਚ ਸਮਝਦੇ ਹਨ: ਇੱਕ "issue token" ਐਂਡਪੌਇੰਟ, authentication middleware ਜੋ ਟੋਕਨ ਨੂੰ ਵੈਲਿਡੇਟ ਕਰਦਾ ਹੈ, ਅਤੇ guards/policies ਜੋ ਪਹਿਚਾਣ ਸਥਾਪਤ ਹੋਣ ਤੋਂ ਬਾਅਦ ਚੱਲਦੇ ਹਨ।
ਟੋਕਨ ਇੱਕ ਐਕਸੈਸ ਕਰਿਡੈਂਸ਼ਲ ਹੁੰਦਾ ਹੈ ਜੋ ਲੌਗਿਨ ਤੋਂ ਬਾਅਦ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜਾਂ OAuth ਫਲੋ ਤੋਂ ਬਾਅਦ)। ਕਲਾਇੰਟ ਇਸਨੂੰ ਬਾਅਦ ਦੀਆਂ ਰਿਕੁਐਸਟਾਂ 'ਤੇ ਭੇਜਦਾ ਹੈ ਤਾਂ ਕਿ ਸਰਵਰ ਕਾਲਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰਕੇ ਫਿਰ ਅਧਿਕਾਰ ਨਿਰਣਾਇਕ ਕਰ ਸਕੇ।
Opaque tokens ਰੈਂਡਮ ਸਟਰਿੰਗ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਕਲਾਇੰਟ ਲਈ ਕੋਈ ਮਤਲਬ ਨਹੀਂ ਰੱਖਦੀਆਂ (ਉਦਾਹਰਣ tX9...)। ਸਰਵਰ ਉਨ੍ਹਾਂ ਨੂੰ ਡੇਟਾਬੇਸ ਜਾਂ ਕੈਸ਼ ਐਂਟਰੀ ਦੇ ਜਰਿਏ ਵੈਲਿਡੇਟ ਕਰਦਾ ਹੈ। ਇਹ ਰਿਵੋਕੇਸ਼ਨ ਨੂੰ ਸਿੱਧਾ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਟੋਕਨ ਸਮੱਗਰੀ ਨੂੰ ਨਿੱਜੀ ਰੱਖਦਾ ਹੈ।
JWTs (JSON Web Tokens) ਸੰਰਚਿਤ ਅਤੇ ਸਾਇੰਡ ਹੁੰਦੀਆਂ ਹਨ। ਇੱਕ JWT ਆਮ ਤੌਰ 'ਤੇ claims ਰੱਖਦਾ ਹੈ ਜਿਵੇਂ user identifier (sub), issuer (iss), audience (aud), issued/expiry times (iat, exp), ਅਤੇ ਕਈ ਵਾਰੀ roles/scopes। ਮਹੱਤਵਪੂਰਨ: JWTs ਮੂਲ ਰੂਪ ਵਿੱਚ ਐਨਕ੍ਰਿਪਟ ਨਹੀਂ ਹੁੰਦੇ—ਉਹ ਸਿਰਫ਼ encode ਕੀਤੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਜੋ ਕੋਈ ਵੀ ਟੋਕਨ ਰੱਖਦਾ ਹੈ ਉਹ claims ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਨਵਾਂ ਟੋਕਨ ਬਣਾਉਣ ਦੀ ਯੋਗਤਾ ਨਾ ਰੱਖਦਾ ਹੋਵੇ।
ਫਰੇਮਵਰਕ ਸੂਝ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟਾਂ ਦੀ ਸਿਫਾਰਿਸ਼ ਕਰਦੇ ਹਨ:
Authorization: Bearer \u003ctoken\u003e ਹੈਡਰ ਰਾਹੀਂ ਐਕਸੈਸ ਟੋਕਨ ਭੇਜੋ। ਇਸ ਨਾਲ ਆਟੋਮੈਟਿਕ ਕੁਕੀ ਭੇਜਣ ਨਾਲ ਜੁੜੇ CSRF ਖਤਰਿਆਂ ਤੋਂ ਬਚਾਅ ਹੁੰਦਾ ਹੈ, ਪਰ XSS ਦੇ ਖ਼ਿਲਾਫ਼ ਰੱਖ-ਰਖਾਵ ਬਰਹਿ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ JavaScript ਆਮ ਤੌਰ 'ਤੇ ਟੋਕਨ ਨੂੰ ਪੜ੍ਹ ਕੇ ਲਗਾ ਸਕਦਾ ਹੈ।HttpOnly, Secure, ਅਤੇ SameSite ਬਣਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ CSRF ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰਨ ਲਈ ਤਿਆਰ ਹੋ (ਅਕਸਰ ਵੱਖਰਾ CSRF ਟੋਕਨ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ)।ਐਕਸੈਸ ਟੋਕਨ ਛੋਟੇ ਸਮੇਂ ਲਈ ਰੱਖੋ। ਲਗਾਤਾਰ ਲੌਗਿਨ ਮੰਗਣ ਤੋਂ ਬਚਣ ਲਈ, ਬਹੁਤ ਸਾਰੇ ਫਰੇਮਵਰਕ refresh tokens ਦਾ ਸਮਰਥਨ ਕਰਦੇ ਹਨ: ਇੱਕ ਲੰਬੀ-ਅਵਧੀ ਕੁੰਜੀ ਜੋ ਸਿਰਫ਼ ਨਵੇਂ ਐਕਸੈਸ ਟੋਕਨ ਬਣਾਉਣ ਲਈ ਵਰਤੀ ਜਾਂਦੀ ਹੈ।
ਆਮ ਬਣਤਰ:
POST /auth/login → returns access token (and refresh token)POST /auth/refresh → rotates the refresh token and returns a new access tokenPOST /auth/logout → invalidates refresh tokens server-sideਰੋਟੇਸ਼ਨ (ਹਰ ਵਾਰੀ ਨਵਾਂ refresh token ਜਾਰੀ ਕਰਨਾ) ਇਸ ਗੱਲ ਨੂੰ ਸੀਮਿਤ ਕਰਦਾ ਹੈ ਕਿ ਜੇ refresh token ਚੋਰੀ ਹੋ ਜਾਵੇ ਤਾਂ ਨੁਕਸਾਨ ਕਿੰਨਾ ਵੱਡਾ ਹੋਵੇ; ਕਈ ਫਰੇਮਵਰਕ token identifiers ਸਟੋਰ ਕਰਨ, reuse ਦੀ ਪਹਚਾਣ ਕਰਨ ਅਤੇ ਤੁਰੰਤ ਰਿਵੋਕੇਸ਼ਨ ਕਰਨ ਲਈ ਹੁੱਕ ਦਿੰਦੇ ਹਨ।
OAuth 2.0 ਅਤੇ OpenID Connect (OIDC) ਅਕਸਰ ਇਕੱਠੇ ਜ਼ਿਕਰ ਹੁੰਦੇ ਹਨ, ਪਰ ਫਰੇਮਵਰਕ ਉਨ੍ਹਾਂ ਨੂੰ ਵੱਖਰਾ ਵੇਖਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਅਤੇ ਉਨ੍ਹਾਂ ਦੀਆਂ auth ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੋ ਫਲੋਜ਼ 'ਤੇ ਧਿਆਨ ਦਿੱਤੀਆਂ ਹਨ:
ਫਰੇਮਵਰਕ ਇੰਟੀਗਰੇਸ਼ਨਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ callback ਰੂਟ ਅਤੇ ਸਹਾਇਕ middleware ਦਿੰਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੁਨਫ਼ਿਗਰ ਕਰਨਾ ਹੁੰਦਾ ਹੈ:
ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਦਾਤਾ ਡੇਟਾ ਨੂੰ ਲੋਕਲ ਯੂਜ਼ਰ ਮਾਡਲ ਵਿੱਚ ਨਾਰਮਲਾਈਜ਼ ਕਰਦੇ ਹਨ। ਮੁੱਖ ਡਿਜ਼ਾਇਨ ਫੈਸਲਾ ਇਹ ਹੈ ਕਿ ਅਸਲ ਵਿੱਚ ਅਧਿਕਾਰ ਨੂੰ ਕੀ ਚਲਾਉਂਦਾ ਹੈ:
ਆਮ ਪੈਟਰਨ: stable identifiers (ਜਿਵੇਂ sub) ਨੂੰ ਲੋਕਲ ਯੂਜ਼ਰ ਨਾਲ ਮੈਪ ਕਰੋ, ਫਿਰ ਪ੍ਰਦਾਤਾ ਦੇ roles/groups/claims ਨੂੰ ਤੁਹਾਡੇ ਐਪ ਦੇ ਲੋਕਲ ਰੋਲ ਜਾਂ ਪਾਲਿਸੀਆਂ ਵਿੱਚ ਤਬਦੀਲ ਕਰੋ।
ਪਾਸਵਰਡ ਅਜੇ ਵੀ ਕਈ ਐਪਸ ਵਿੱਚ ਡਿਫਾਲਟ ਸਾਈਨ-ਇਨ ਤਰੀਕਾ ਹਨ, ਇਸ ਲਈ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਸੁਰੱਖਿਅਤ ਸਟੋਰੇਜ ਪੈਟਰਨ ਅਤੇ ਗਾਰਡਰੇਲਜ਼ ਨਾਲ ਆਉਂਦੇ ਹਨ। ਕੁੰਜੀ ਨਿਯਮ ਇਹ ਹੈ: ਕਦੇ ਵੀ ਪਾਸਵਰਡ (ਜਾਂ ਸਧਾਰਨ ਹੈਸ਼) ਨੂੰ ਡੇਟਾਬੇਸ ਵਿੱਚ ਸਟੋਰ ਨਾ ਕਰੋ।
ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇbcrypt, Argon2, ਜਾਂ scrypt ਵਰਗੇ ਉਦੇਸ਼-ਨਿਰਧਾਰਤ ਪਾਸਵਰਡ hashers ਨੂੰ ਡਿਫਾਲਟ ਰੱਖਦੇ ਹਨ। ਇਹ ਅਲਗੋਰਿਥਮ ਜਾਣਬੂਝ ਕੇ ਹੌਲੀ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ salting ਸ਼ਾਮਲ ਕਰਦੀਆਂ ਹਨ, ਜੋ precomputed table ਹਮਲਿਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ ਬ੍ਰੂਟ ਫੋਰਸ ਟਾਈਮ ਵਧਾਉਂਦਾ ਹੈ।
ਸਧਾਰਨ ਕ੍ਰਿਪਟੋਗ੍ਰਾਫਿਕ ਹੈਸ਼ (ਜਿਵੇਂ SHA-256) ਪਾਸਵਰਡ ਲਈ ਅਸੁਰੱਖਿਅਤ ਹੈ ਕਿਉਂਕਿ ਇਹ ਤੇਜ਼ ਬਣਾਈ ਜਾਂਦੀ ਹੈ; ਡੇਟਾਬੇਸ ਲੀਕ ਹੋਣ 'ਤੇ ਅਟੈਕਰ ਤੇਜ਼ੀ ਨਾਲ ਅਨਗਿਣਤ ਪਾਸਵਰਡ ਅਨੁਮਾਨ ਕਰ ਸਕਦੇ ਹਨ। ਪਾਸਵਰਡ hashers ਵਿੱਚ work factors (cost parameters) ਹੁੰਦੇ ਹਨ ਤਾਂ ਕਿ ਤੁਸੀਂ ਸਮਾਂ-ਸਮਾਂ 'ਤੇ ਸੁਰੱਖਿਆ ਟਿਊਨ ਕਰ ਸਕੋ।
ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ hooks ਜਾਂ middleware/plugins ਦਿੰਦੇ ਹਨ ਤਾਂ ਕਿ ਸਮਝਦਾਰ ਨੀਤੀਆਂ ਲਾਗੂ ਕੀਤੀਆਂ ਜਾ ਸਕਣ:
ਅਧਿਕাংশ ਈਕੋਸਿਸਟਮ MFA ਲਗਾਉਣ ਦੀ ਸਹਾਇਤਾ ਕਰਦੇ ਹਨ:
ਪਾਸਵਰਡ ਰੀਸੈੱਟ ਆਮ ਹਮਲਾ ਰਾਹ ਹੈ, ਇਸ ਲਈ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪੈਟਰਨ ਦਰਸਾਉਂਦੇ ਹਨ:
ਅਚਛਾ ਨਿਯਮ: ਵੈਧ ਯੂਜ਼ਰ ਲਈ ਰਿਕਵਰੀ ਆਸਾਨ ਕਰੋ, ਪਰ ਹਮਲਾਵਰ ਲਈ ਆਟੋਮੇਸ਼ਨ ਮਹਿੰਗੀ ਬਣਾਓ।
ਜ਼ਿਆਦਾਤਰ ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਸੁਰੱਖਿਆ ਨੂੰ ਰਿਕੁਐਸਟ ਪਾਈਪਲਾਈਨ ਦਾ ਹਿੱਸਾ ਮੰਨਦੇ ਹਨ: ਉਹ ਕਦਮਾਂ ਦੀ ਲੜੀ ਜੋ ਤੁਹਾਡੇ handler/controller ਤੋਂ ਪਹਿਲਾਂ (ਅਤੇ ਕਈ ਵਾਰੀ ਬਾਅਦ) ਚਲਦੇ ਹਨ। ਨਾਮ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ—middleware, filters, guards, interceptors—ਪਰ ਮਕਸਦ ਇੱਕੋ: ਹਰ ਕਦਮ ਰਿਕੁਐਸਟ ਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਹੈ, ਸੰਦਰਭ ਜੋੜ ਸਕਦਾ ਹੈ, ਜਾਂ ਪ੍ਰੋਸੈਸਿੰਗ ਰੋਕ ਸਕਦਾ ਹੈ।
ਆਮ ਫਲੋ ਆਮ ਤੌਰ 'ਤੇ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦਾ ਹੈ:
/account/settings).ਫਰੇਮਵਰਕ ਤੁਹਾਨੂੰ ਸਲਾਹ ਦਿੰਦੇ ਹਨ ਕਿ ਸੁਰੱਖਿਆ ਚੈੱਕ ਬਿਜ਼ਨਸ ਲਾਜਿਕ ਤੋਂ ਬਾਹਰ ਰੱਖੋ, ਤਾਂ ਜੋ controllers "ਕੀ ਕਰਨਾ ਹੈ" 'ਤੇ ਧਿਆਨ ਦੇਉਂ, ਨਾ ਕਿ "ਕੌਣ ਕਰ ਸਕਦਾ ਹੈ" 'ਤੇ।
ਪ੍ਰਮਾਣਿਕਤਾ ਉਹ ਕਦਮ ਹੈ ਜਿੱਥੇ ਫਰੇਮਵਰਕ cookies, session IDs, API keys, ਜਾਂ bearer tokens ਤੋਂ user context ਸਥਾਪਤ ਕਰਦਾ ਹੈ। ਜੇ ਸਫਲ ਹੁੰਦਾ ਹੈ, ਇਹ ਇੱਕ request-scoped identity ਬਣਾਉਂਦਾ—ਅਕਸਰ user, principal, ਜਾਂ context.auth ਵਜੋਂ ਐਕਸਪੋਜ਼ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇਹ ਚੀਜ਼ ਅਹਮ ਹੈ ਕਿਉਂਕਿ ਬਾਅਦ ਦੇ ਕਦਮ (ਅਤੇ ਤੁਹਾਡਾ ਐਪ ਕੋਡ) headers ਨੂੰ ਦੁਬਾਰਾ 파arse ਜਾਂ ਟੋਕਨ ਨੂੰ ਦੁਬਾਰਾ ਵੈਲਿਡੇਟ ਨਹੀਂ ਕਰਨੇ ਚਾਹੀਦੇ। ਉਹ ਪਹਿਲਾਂ ਭਰੀ ਹੋਈ user object ਨੂੰ ਪੜ੍ਹਣ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ:
ਅਧਿਕਾਰ ਆਮ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ:
ਦੂਜਾ ਕਿਸਮ ਇਸ ਲਈ controllers ਅਤੇ ਸੇਵਾਵਾਂ ਦੇ ਨੇੜੇ ਬੈਠਦੀ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਅਕਸਰ route params ਜਾਂ ਡੇਟਾਬੇਸ-ਲੋਡ ਕੀਤੇ ਵਸਤੂਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਸਹੀ ਨਿਰਣੇ ਲਈ।
ਫਰੇਮਵਰਕ ਅਕਸਰ ਦੋ ਆਮ ਅਸਫਲਤਾ ਮੋਡ ਵੱਖ ਕਰਦੇ ਹਨ:
ਚੰਗੇ ਡਿਜ਼ਾਇਨ ਕੀਤੇ ਸਿਸਟਮ 403 ਰਿਸਪਾਂਸ ਵਿੱਚ ਵੇਰਵੇ ਨਾ ਲਿਕ ਕਰਦੇ; ਉਹ ਬਿਨਾਂ ਇਹ ਦੱਸੇ ਪਹੁੰਚ ਰੋਕ ਦਿੰਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਨਿਯਮ ਫੇਲ ਹੋਇਆ।
ਅਧਿਕਾਰ ਇਹ ਸਵਾਲ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ: “ਇਹ ਸਾਈਨ-ਇਨ ਯੂਜ਼ਰ ਇਸ ਵੇਲੇ ਇਹ ਖਾਸ ਕੰਮ ਕਰਨ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ ਜਾਂ ਨਹੀਂ?” ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਮਾਡਲ ਸਮਰਥਨ ਕਰਦੇ ਹਨ, ਤੇ ਬਹੁਤ ਟੀਮਾਂ ਇਨ੍ਹਾਂ ਨੂੰ ਮਿਲਾ ਕੇ ਵਰਤਦੀਆਂ ਹਨ।
RBAC ਯੂਜ਼ਰ ਨੂੰ ਇੱਕ ਜਾਂ ਵੱਧ ਰੋਲ(ਜਿਵੇਂ admin, support, member) ਦੇਂਦਾ ਹੈ ਅਤੇ ਫੀਚਰਾਂ ਨੂੰ ਉਨ੍ਹਾਂ ਰੋਲਾਂ ਤੇ ਆਧਾਰਿਤ ਗੇਟ ਕਰਦਾ ਹੈ।
ਇਹ ਸੋਚਣ ਵਿੱਚ ਆਸਾਨ ਅਤੇ ਲਾਗੂ ਕਰਨ ਵਿੱਚ ਤੇਜ਼ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਫਰੇਮਵਰਕ requireRole('admin') ਵਰਗੇ ਸਹਾਇਕ ਦਿੰਦੇ ਹਨ। ਰੋਲ ਹਾਇਰਾਰਕੀਜ਼ ("admin implies manager implies member") ਡਿਊਪਲੀਕੇਸ਼ਨ ਘਟਾ ਸਕਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਪ੍ਰਿਵਿਲੇਜ ਛਿਪਾ ਸਕਦੀਆਂ ਹਨ: ਇੱਕ ਛੋਟਾ ਬਦਲਾਅ ਪੈਰੇਂਟ ਰੋਲ ਵਿੱਚ ਬਿਨਾਂ ਧਿਆਨ ਦਿੱਤੇ ਐਪ 'ਚ ਚੌੜੇ ਤੌਰ 'ਤੇ ਪਹੁੰਚ ਦੇ ਸਕਦਾ ਹੈ।
RBAC ਵੱਡੇ, ਸਥਿਰ ਫ਼ਰਕਾਂ ਲਈ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ।
Permission-ਆਧਾਰਿਤ ਅਧਿਕਾਰ ਕਿਸੇ ਐਕਸ਼ਨ ਨੂੰ ਇੱਕ ਰਿਸੋਰਸ ਖਿਲਾਫ ਮੁਕਾਬਲਾ ਕਰਦਾ ਹੈ, ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ:
read, create, update, delete, inviteinvoice, project, user, ਕਈ ਵਾਰੀ ID ਜਾਂ ownership ਸਮੇਤਇਹ ਮਾਡਲ RBAC ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਠੀਕ ਹੈ। ਉਦਾਹਰਣ ਲਈ, “can update projects” ਅਤੇ “can update only projects they own” ਵਿੱਚ ਫ਼ਰਕ ਹੈ—ਇਸ ਲਈ ਦੋਹਾਂ ਪਰਮੀਸ਼ਨ ਅਤੇ ਡੇਟਾ ਸ਼ਰਤਾਂ ਦੀ ਜਾਂਚ ਲੋੜੀਂਦੀ ਹੈ।
ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕੇਂਦਰੀ “can?” ਫੰਕਸ਼ਨ (ਜਾਂ ਸੇਵਾ) ਦੇ ਰਾਹੀਂ ਇਹ ਲਾਗੂ ਕਰਦੇ ਹਨ ਜੋ controllers, resolvers, workers, ਜਾਂ templates ਵਿੱਚ ਬੁਲਾਇਆ ਜਾਂਦਾ ਹੈ।
ਪਾਲਿਸੀਆਂ ਅਧਿਕਾਰ ਲਾਜਿਕ ਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ ਮੁਲਾਂਕਣਕਾਰਾਂ ਵਿੱਚ ਪੈਕ ਕਰਦੀਆਂ ਹਨ: “ਇੱਕ ਯੂਜ਼ਰ ਇੱਕ ਕਮੈਂਟ ਨੂੰ ਮਿਟਾ ਸਕਦਾ ਹੈ ਜੇ ਉਹ ਉਸਦਾ ਲੇਖਕ ਹੋਵੇ ਜਾਂ ਉਹ ਇੱਕ moderator ਹੋਵੇ।” ਪਾਲਿਸੀਆਂ context (user, resource, request) ਲੈ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਉਹ ਉੱਤਮ ਹਨ:
ਜਦੋਂ ਫਰੇਮਵਰਕ ਪਾਲਿਸੀਆਂ ਨੂੰ routing ਅਤੇ middleware ਨਾਲ ਇੰਟੀਗ੍ਰੇਟ ਕਰਦੇ ਹਨ, ਤੁਸੀਂ ਨਿਯਮਾਂ ਨੂੰ ਇੱਕਸਾਰ ਤੌਰ 'ਤੇ ਹਰ ਏਂਡਪੌਇੰਟ 'ਤੇ ਲਾਗੂ ਕਰ ਸਕਦੇ ਹੋ।
Annotations (ਜਿਵੇਂ @RequireRole('admin')) ਇਰਾਦਾ handler ਦੇ ਨੇੜੇ ਰੱਖਦੇ ਹਨ, ਪਰ ਜਦੋਂ ਨਿਯਮ ਜਟਿੱਲ ਹੋ ਜਾਂਦੇ ਹਨ ਤਾਂ ਵੱਖ-ਵੱਖ ਹੋ ਸਕਦੇ ਹਨ।
ਕੋਡ-ਅਧਾਰਿਤ ਚੈੱਕ (ਅਧਿਕਾਰ-ਨਿਰਧਾਰਕ ਨੂੰ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਕਾਲ ਕਰਨਾ) ਜ਼ਿਆਦਾ verbose ਹੁੰਦੇ ਹਨ, ਪਰ ਆਮ ਤੌਰ 'ਤੇ ਟੈਸਟ ਅਤੇ ਰੀਫੈਕਟਰ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੇ ਹਨ। ਆਮ ਸਮਝੌਤਾ: coarse gates ਲਈ annotations ਅਤੇ detailed logic ਲਈ policies।
ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਸਿਰਫ਼ ਯੂਜ਼ਰਾਂ ਨੂੰ ਲੌਗਿਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਦੇ—ਉਹ ਆਮ "web glue" ਹਮਲਿਆਂ ਲਈ ਰੱਖਿਆ ਵੀ ਸਾਂਭਦੇ ਹਨ ਜੋ ਪ੍ਰਮਾਣਿਕਤਾ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਹੁੰਦੇ ਹਨ।
ਜੇ ਤੁਹਾਡਾ ਐਪ session cookies ਵਰਤਦਾ ਹੈ, ਤਾਂ ਬਰਾਊਜ਼ਰ ਆਟੋਮੈਟਿਕ ਤੌਰ ਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਰਿਕੁਐਸਟਾਂ 'ਤੇ ਅਟੈਚ ਕਰਦਾ ਹੈ—ਕਈ ਵਾਰੀ ਹੋਰ ਸਾਈਟ ਤੋਂ ਟ੍ਰਿੱਗਰ ਕਿੱਤੇ ਗਏ ਦਰਮਿਆਨ ਵੀ। ਫਰੇਮਵਰਕ CSRF ਰੱਖਿਆ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਤੀ-ਸੈਸ਼ਨ (ਜਾਂ ਪ੍ਰਤੀ-ਰਿਕੁਐਸਟ) CSRF ਟੋਕਨ ਜੋੜਦੀ ਹੈ ਜੋ state-changing ਰਿਕੁਐਸਟਾਂ ਨਾਲ ਭੇਜਣਾ ਲਾਜ਼ਮੀ ਹੁੰਦਾ ਹੈ।
ਆਮ ਪੈਟਰਨ:
CSRF ਟੋਕਨਾਂ ਨੂੰ SameSite cookies (ਅਕਸਰ Lax) ਨਾਲ ਜੋੜੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ session cookie HttpOnly ਅਤੇ Secure ਹੈ ਜਿੱਥੇ ਲੋੜੀਦਾ ਹੋਵੇ।
CORS ਇੱਕ auth ਮਕੈਨੀਜ਼ਮ ਨਹੀਂ; ਇਹ ਬ੍ਰਾਊਜ਼ਰ ਪਰਮਿਸ਼ਨ ਸਿਸਟਮ ਹੈ। ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ middleware/config ਦਿੰਦੇ ਹਨ ਜੋ ਭਰੋਸੇਯੋਗ origins ਨੂੰ ਤੁਹਾਡਾ API ਕਾਲ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ।
ਗਲਤ ਕੰਫਿਗਰੇਸ਼ਨਾਂ ਤੋਂ ਬਚੋ:
Access-Control-Allow-Origin: * ਨਾਲ Access-Control-Allow-Credentials: true (ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਰੀਜੈਕਟ ਕਰੇਗਾ, ਅਤੇ ਇਹ ਗਲਤ ਸੰਕੇਤ ਹੈ)Origin header ਨੂੰ ਬਿਨਾਂ ਕਸ੍ਟ allowlist ਦੇ ਵਾਪਸ ਪਰਿਵਰਤਿਤ ਕਰਨਾAuthorization) ਜਾਂ methods ਭੁੱਲ ਜਾਣਾ, ਜਿਸ ਨਾਲ ਕਲਾਇੰਟ "curl ਵਿੱਚ ਚੱਲਦਾ ਪਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਫੇਲ" ਤਜਰਬਾ ਕਰਦਾ ਹੈਜ਼ਿਆਦਾਤਰ ਫਰੇਮਵਰਕ ਸੁਰੱਖਿਅਤ ਡਿਫਾਲਟ ਸੈਟ ਕਰਨ ਜਾਂ ਆਸਾਨੀ ਨਾਲ ਹੇਡਰ ਜੋੜਨ ਦੀ ਸਹੂਲਤ ਦਿੰਦੇ ਹਨ:
X-Frame-Options ਜਾਂ Content-Security-Policy: frame-ancestors ਨਾਲ clickjacking ਰੋਕੋContent-Security-Policy (ਵਿਆਪਕ ਸਕ੍ਰਿਪਟ/ਰਿਸੋਰਸ ਕੰਟਰੋਲ)Referrer-Policy ਅਤੇ X-Content-Type-Options: nosniff ਜਿਵੇਂ ਹੈਡਰ ਬਰਾਊਜ਼ਰ ਵਿਹਾਰ ਨੂੰ ਸੁਰੱਖਿਅਤ ਬਣਾਉਂਦੇ ਹਨਵੈਧਤਾ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਡੇਟਾ ਚੰਗੇ ਫਾਰਮ ਵਿੱਚ ਹੈ; ਅਧਿਕਾਰ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਯੂਜ਼ਰ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਆਗਿਆ ਰੱਖਦਾ ਹੈ। ਇੱਕ ਵੈਧ ਰਿਕੁਐਸਟ ਬੀ ਫਿਰ ਵੀ ਮਨਾਹੀ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ—ਫਰੇਮਵਰਕ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲਾਂ ਇਨਪੁੱਟ ਵੈਧਤਾ ਕਰੋ, ਫਿਰ ਖਾਸ ਰਿਸੋਰਸ ਉੱਤੇ ਪਰਮੀਸ਼ਨ ਲਾਗੂ ਕਰੋ।
ਸਹੀ auth ਪੈਟਰਨ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਕਿੱਥੇ ਚੱਲਦਾ ਹੈ ਅਤੇ ਕਿਵੇਂ ਬੇਕਐਂਡ ਤੱਕ ਰਿਕੁਐਸਟ ਪਹੁੰਚਦੇ ਹਨ। ਫਰੇਮਵਰਕ ਕਈ ਵਿਕਲਪਾਂ ਨੂੰ ਸਮਰਥਨ ਕਰ ਸਕਦੇ ਹਨ, ਪਰ ਇੱਕ ਐਪ ਕਿਸਮ ਵਿੱਚ ਜੋ ਡਿਫਾਲਟ ਸੁਭਾਵਕ ਲੱਗਦਾ ਹੈ ਉਹ ਦੂਜੀ ਵਿੱਚ ਅਸੁਖੁਲ ਜਾਂ ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ।
SSR ਫਰੇਮਵਰਕ ਸਾਹਮਣੇ cookie-ਆਧਾਰਿਤ sessions ਨਾਲ ਸਭ ਤੋਂ ਵਧੀਆ ਜੋੜਦੇ ਹਨ। ਬਰਾਊਜ਼ਰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ 쿠ਕੀ ਭੇਜਦਾ ਹੈ, ਸਰਵਰ ਸੈਸ਼ਨ ਲੁੱਕਅੱਪ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੰਨੇ user context ਨਾਲ ਰੈਂਡਰ ਹੋ ਸਕਦੇ ਹਨ ਬਿਨਾਂ ਵੱਧ ਕਲਾਇੰਟ ਕੋਡ ਦੇ।
ਪ੍ਰਯੋਗਿਕ ਨਿਯਮ: session cookies ਨੂੰ HttpOnly, Secure, ਅਤੇ ਮੰਜ਼ੂਰਿ-ਯੋਗ SameSite ਰੱਖੋ, ਅਤੇ ਹਰ ਪ੍ਰਾਈਵੇਟ ਡੇਟਾ ਰੈਂਡਰ ਕਰਨ ਵਾਲੀ ਰਿਕੁਐਸਟ 'ਤੇ ਸਰਵਰ-ਸਾਈਡ ਅਧਿਕਾਰ ਚੈੱਕ ਲਗਾਓ।
SPAs ਅਕਸਰ JavaScript ਰਾਹੀਂ APIs ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਟੋਕਨ ਚੋਣਾਂ ਹੋਰ ਵੇਖਣਯੋਗ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। ਕਈ ਟੀਮਾਂ ਇੱਕ OAuth/OIDC ਫਲੋ ਪਸੰਦ ਕਰਦੀਆਂ ਹਨ ਜੋ ਛੋਟੇ ਸਮੇਂ ਵਾਲੇ access tokens ਦਿੰਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਲੰਬੇ-ਮਿਆਦੀ ਟੋਕਨਾਂ ਨੂੰ localStorage ਵਿੱਚ ਰੱਖਦੇ ਹੋ ਤਾਂ XSS ਦਾ blast radius ਵੱਧ ਜਾਂਦਾ ਹੈ—ਇਸ ਲਈ ਇਸ ਤੋਂ ਬਚੋ ਜਦੋਂ ਸੰਭਵ ਹੋਵੇ। ਇੱਕ ਆਮ ਵਿਕਲਪ backend-for-frontend (BFF) ਪੈਟਰਨ ਹੈ: SPA ਤੁਹਾਡੇ ਸਰਵਰ ਨਾਲ session cookie ਰਾਹੀਂ ਗੱਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ upstream APIs ਲਈ ਟੋਕਨ ਐਕਸਚੇਂਜ/ਹੋਲਡ ਕਰਦਾ ਹੈ।
ਮੋਬਾਈਲ ਐਪਸ ਬਰਾਊਜ਼ਰ ਕੁਕੀ ਨਿਯਮਾਂ ਤੇ ਵਿਸ਼ਵਾਸ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ। ਉਹ ਆਮ ਤੌਰ 'ਤੇ PKCE ਸਮੇਤ OAuth/OIDC ਵਰਤਦੀਆਂ ਹਨ, ਅਤੇ refresh tokens ਨੂੰ platform ਦੇ secure storage (Keychain/Keystore) ਵਿੱਚ ਰੱਖਦੀਆਂ ਹਨ।
"ਲੋਸਟ ਡਿਵਾਈਸ" ਰਿਕਵਰੀ ਲਈ ਯੋਜਨਾ ਬਣਾਓ: refresh tokens ਰਿਵੋਕੇਟ ਕਰੋ, ਕਰਿਡੈਂਸ਼ਲ ਰੋਟੇਟ ਕਰੋ, ਅਤੇ ਮੁੜ-ਪ੍ਰਮਾਣਿਕਤਾ ਅਸਾਨ ਬਣਾਓ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ MFA ਚਾਲੂ ਹੋਵੇ।
ਕਈ ਸੇਵਾਵਾਂ ਹੋਣ 'ਤੇ ਤੁਹਾਨੂੰ centralized identity ਅਤੇ service-level enforcement ਵਿਚਕਾਰ ਚੋਣ ਕਰਨੀ ਹੋਵੇਗੀ:
ਸੇਵਾ-ਤੋਂ-ਸੇਵਾ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ, ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ mTLS (ਮਜ਼ਬੂਤ ਚੈਨਲ ਪਹਿਚਾਣ) ਜਾਂ OAuth client credentials (service accounts) ਨਾਲ ਇੰਟੀਗ੍ਰੇਟ ਕਰਦੇ ਹਨ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਕਾਲਰ ਦੀ ਪ੍ਰਮਾਣਿਕਤਾ ਕਰੋ ਅਤੇ ਇਹ ਫੈਸਲਾ ਕਰੋ ਕਿ ਉਹ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।
Admin "impersonate user" ਫੀਚਰ طاقتਵਰ ਪਰ ਖਤਰਨਾਕ ਹਨ। ਖੁਸ਼ਮਾਨਾ impersonation sessions ਦੀ ਪਸੰਦ ਕਰੋ, admins ਲਈ re-authentication/MFA ਦੀ ਲੋੜ ਰੱਖੋ, ਅਤੇ ਹਮੇਸ਼ਾਂ ਆਡੀਟ ਲੌਗ ਲਿਖੋ (ਕਿਸਨੇ ਕਿਸਨੂੰ impersonate ਕੀਤਾ, ਕਦੋਂ, ਅਤੇ ਕੀ ਕਾਰਵਾਈ ਕੀਤੀ ਗਈ)।
ਸੁਰੱਖਿਆ ਫੀਚਰ ਤਦ ਹੀ ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਕੋਡ ਬਦਲਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰਦੇ ਰਹਿਣ। ਆਧੁਨਿਕ ਫਰੇਮਵਰਕ ਪ੍ਰਮਾਣਿਕਤਾ ਅਤੇ ਅਧਿਕਾਰ ਦੀ ਟੈਸਟਿੰਗ ਆਸਾਨ ਬਣਾਉਂਦੇ ਹਨ, ਪਰ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਟੈਸਟ ਲਾੜਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸਲੀ ਯੂਜ਼ਰ ਤੇ ਅਸਲ ਹਮਲਾਵਰ ਦੇ ਵਰਤਾਰਿਆਂ ਨੂੰ ਦਰਸਾਉਂਦੇ ہوں।
ਕੀ ਤੁਸੀਂ ਟੈਸਟ ਕਰਦੇ ਹੋ ਉਸ ਨੂੰ ਵੱਖਰਾ ਕਰੋ:
ਜ਼ਿਆਦਾਤਰ ਫਰੇਮਵਰਕ ਟੈਸਟ ਹਲਾਂ ਦਿੰਦੇ ਹਨ ਜਿੰਨਾਂ ਨਾਲ ਤੁਹਾਨੂੰ ਹਰ ਵਾਰੀ sessions ਜਾਂ tokens ਹੱਥੋਂ-ਹੱਥ ਬਣਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਪੈਂਦੀ। ਆਮ ਪੈਟਰਨ:
ਪਰਯੋਗਿਕ ਨਿਯਮ: ਹਰ “happy path” ਟੈਸਟ ਲਈ ਇੱਕ “should be denied” ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਸਾਬਤ ਕਰੇ ਕਿ authorization ਚੈੱਕ ਅਸਲ ਵਿੱਚ ਚੱਲਦਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਇਨ੍ਹਾਂ ਫਲੋਜ਼ਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੇਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੇਜ਼ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ ਰੋਲਬੈਕ ਸਹਾਇਕ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਣ ਲਈ, Koder.ai (ਇਕ vibe-coding ਪਲੇਟਫਾਰਮ) React front end ਅਤੇ Go + PostgreSQL ਬੈਕਐਂਡ ਚੈਟ-ਆਧਾਰਤ ਸਪੈੱਕ 'ਤੋਂ ਜਨਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਫਿਰ snapshots ਅਤੇ rollback ਦੀ ਸਹੂਲਤ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ middleware/guards ਅਤੇ policy checks ਨੂੰ ਸੁਧਾਰ ਰਹੇ ਹੋ—ਇਹ ਉਦਾਹਰਣ ਸਿਰਫ਼ ਜਾਣਕਾਰੀ ਲਈ ਹੈ।
ਜਦੋਂ ਕੁਝ ਗਲਤ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਜਲਦੀ ਅਤੇ ਭਰੋਸੇਯੋਗ ਜਵਾਬ ਚਾਹੀਦੇ ਹਨ।
ਮੁੱਖ ਘਟਨਾਵਾਂ ਲੌਗ/ਆਡੀਟ ਕਰੋ:
ਸਾਥ ਹੀ ਕੁਝ ਹਲਕੇ metrics ਸ਼ਾਮਲ ਕਰੋ: 401/403 ਦੀ ਦਰ, failed login ਵਿੱਚ spikes, ਅਤੇ ਅਸਧਾਰਨ token refresh ਪੈਟਰਨ।
ਅਧਿਕਾਰ ਬੱਗਾਂ ਨੂੰ ਟੈਸਟਯੋਗ ਵਿਹਾਰ ਸਮਝੋ: ਜੇ ਇਹ regress ਕਰ ਸਕਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੇ ਲਾਇਕ ਇੱਕ ਟੈਸਟ ਬਣਾਓ।
Authentication proves identity (who is making the request). Authorization decides access (what that identity may do) using context like route, resource ownership, tenant, and scopes.
Frameworks separate them so you can change sign-in methods without rewriting permission logic.
Most frameworks enforce auth in a request pipeline, typically with:
user/principalAn identity store is the source of truth for users and credentials (or links to external identities). A user model is how your code represents that identity.
In practice, frameworks need both to answer: “given this identifier/token, who is the current user?”
Common sources include:
When using an IdP/directory, many apps keep a “shadow user” locally to map stable external IDs (like OIDC sub) to app-specific roles and data.
Sessions store identity server-side and use a cookie as a pointer (session ID). They’re great for SSR and make revocation simple.
Tokens (JWT/opaque) are sent on each request (often via Authorization: Bearer ...) and fit APIs, SPAs, mobile, and service-to-service use cases.
Frameworks typically harden session cookies with:
HttpOnly (reduces cookie theft via XSS)Secure (HTTPS only)SameSite (limits cross-site sending; affects CSRF and login flows)You still need to choose values appropriate for your app (e.g., vs for cross-site flows).
Opaque tokens are random strings validated by a server lookup (easy revocation, private contents).
JWTs are signed, self-contained tokens with readable claims (e.g., sub, exp, roles/scopes). They’re convenient for distributed systems, but revocation is harder unless you add short expirations and server-side controls (deny lists, token versioning, etc.).
Keep access tokens short-lived, and use refresh tokens only to mint new access tokens.
Common endpoints:
POST /auth/login → access + refreshPOST /auth/refresh → rotate refresh token + issue new accessPOST /auth/logout → invalidate refresh tokensRotation plus reuse detection limits damage if a refresh token leaks.
OAuth 2.0 is for delegated API access (“let this app call an API for me”).
OpenID Connect (OIDC) is for login/identity (“who is the user?”) and adds ID tokens and standardized identity claims.
“Login with X” is typically OIDC built on OAuth 2.0.
RBAC (roles) is simple for broad gates (e.g., admin vs member). Permissions/policies handle fine-grained rules (e.g., edit only your own document).
A common pattern is:
LaxNone