VPN ਦੇ ਅੰਦਰ OAuth: ਕਿਹੜੇ ਪੜਾਵਾਂ ਨੂੰ ਅਜੇ ਵੀ TLS ਦੀ ਲੋੜ ਹੈ
VPN ਬਦਲਦਾ ਹੈ ਕਿ ਕੌਣ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ OAuth ਸੁਨੇਹੇ ਕਿਵੇਂ ਸਫ਼ਰ ਕਰਦੇ ਹਨ। ਪੜਾਅ ਅਨੁਸਾਰ ਫੈਸਲਾ ਕਰੋ: ਅਧਿਕਾਰ ਪ੍ਰਤੀਕਿਰਿਆ, ਟੋਕਨ ਬੇਨਤੀ ਅਤੇ ਬੇਅਰਰ ਕਾਲ।
ਨਿੱਜੀ ਰੂਟਿੰਗ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਕੌਣ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ; OAuth ਦੇ ਆਵਾਜਾਈ ਨਿਯਮ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਹਰ ਸੁਨੇਹਾ ਕਿਵੇਂ ਸਫ਼ਰ ਕਰਦਾ ਹੈ। ਇੱਕ ਬ੍ਰਾਊਜ਼ਰ, ਇੱਕ ਅਧਿਕਾਰ ਸਰਵਰ, ਇੱਕ ਟੋਕਨ ਐਂਡਪੌਇੰਟ ਅਤੇ ਇੱਕ ਸਰੋਤ ਸਰਵਰ ਸਾਰੇ ਇੱਕੋ VPN ਪਿੱਛੇ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਫਿਰ ਵੀ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ ਰਾਹੀਂ ਸੁਨੇਹਿਆਂ ਦਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ। ਹਰ ਪੜਾਅ ਦੀ ਆਪਣੀ ਆਵਾਜਾਈ ਲੋੜ ਹੈ, ਅਤੇ VPN ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਢਿੱਲੀ ਨਹੀਂ ਕਰਦਾ। VPN ਦੀ ਹੱਦ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਹੱਦ ਦੋ ਵੱਖਰੀਆਂ ਰੇਖਾਵਾਂ ਹਨ।
ਫੈਸਲਾ ਸੌਖਾ ਹੋ ਜਾਂਦਾ ਹੈ ਜੇ ਤੁਸੀਂ ਇਹ ਪੁੱਛਣਾ ਛੱਡ ਦਿਓ ਕਿ ਨੈੱਟਵਰਕ ਭਰੋਸੇਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ ਅਤੇ ਇਹ ਪੁੱਛਣਾ ਸ਼ੁਰੂ ਕਰੋ ਕਿ ਕਿਹੜਾ ਆਦਾਨ-ਪ੍ਰਦਾਨ ਕਿਹੜੀ ਹੱਦ ਪਾਰ ਕਰਦਾ ਹੈ।
ਨੈੱਟਵਰਕ ਨਾਲ ਨਹੀਂ, ਪੜਾਅ ਨਾਲ ਫੈਸਲਾ ਕਰੋ
ਐਂਡਪੌਇੰਟ ਵੱਖਰੇ ਲਿਖੋ: ਅਧਿਕਾਰ ਐਂਡਪੌਇੰਟ, ਟੋਕਨ ਐਂਡਪੌਇੰਟ, ਰੀਡਾਇਰੈਕਟ URI, ਸਰੋਤ ਸਰਵਰ ਦਾ URL, TLS ਸਮਾਪਤੀ ਬਿੰਦੂ ਅਤੇ VPN ਗੇਟਵੇ। ਫਿਰ ਚਿੰਨ੍ਹਿਤ ਕਰੋ ਕਿ ਕਿਹੜਾ ਧਿਰ ਹਰ ਬੇਨਤੀ ਸ਼ੁਰੂ ਕਰਦੀ ਹੈ ਅਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਕਿੱਥੇ ਜਾਂਦੀ ਹੈ।
ਗੇਟਵੇ 'ਤੇ ਸਮਾਪਤ ਹੋਣ ਵਾਲਾ VPN ਉਸ ਗੇਟਵੇ ਤੱਕ ਦਾ ਹਿੱਸਾ ਐਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਬੇਨਤੀ ਇਸਦੇ ਪਿੱਛੇ ਆਮ HTTP ਵਜੋਂ ਜਾਰੀ ਰਹਿ ਸਕਦੀ ਹੈ, ਅਤੇ ਪਿਛਲਾ ਹਿੱਸਾ ਐਨਕ੍ਰਿਪਟ ਹੋਣ ਕਾਰਨ ਉਹ ਬਾਕੀ ਪੜਾਅ HTTPS ਨਹੀਂ ਬਣਿਆ। ਇਹੀ ਨਿਰੰਤਰਤਾ ਉਹ ਪੜਾਅ ਹੈ ਜਿਸਦੀ ਪ੍ਰੋਟੋਕੋਲ ਨੂੰ ਪਰਵਾਹ ਹੈ। ਪਹਿਲੀ ਛਾਲ ਐਨਕ੍ਰਿਪਟ ਕਰਨਾ ਦੂਜੀ ਛਾਲ ਨੂੰ ਸੁਰੱਖਿਅਤ ਨਹੀਂ ਬਣਾਉਂਦਾ।
ਆਵਾਜਾਈ ਸੇਵਾ-ਪਛਾਣ ਦੀ ਜਾਂਚ ਵੀ ਲੈ ਕੇ ਚੱਲਦੀ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ URL ਲਈ ਸਰਟੀਫਿਕੇਟ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ; VPN ਬ੍ਰਾਊਜ਼ਰ ਵੱਲੋਂ ਉਹ ਜਾਂਚ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਅਣਪੁਸ਼ਟ ਐਂਡਪੌਇੰਟ ਨੂੰ ਸਵੀਕਾਰਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਸਰਟੀਫਿਕੇਟ ਉਸ ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਕਲਾਇੰਟ ਕਾਲ ਕਰ ਰਿਹਾ ਹੈ ਇੰਝ ਮੰਨਦਾ ਹੈ। ਗੇਟਵੇ ਵੱਲ ਜਾਣ ਵਾਲੀ ਸੁਰੰਗ ਉਸ ਐਂਡਪੌਇੰਟ ਦਾ ਨਾਮ ਨਹੀਂ ਬਦਲਦੀ ਅਤੇ ਨਾ ਹੀ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਦੀ ਹੈ।
ਅਧਿਕਾਰ ਪ੍ਰਤੀਕਿਰਿਆ ਅਤੇ ਰੀਡਾਇਰੈਕਟ URI
OAuth ਦੀ ਮੌਜੂਦਾ ਸਭ ਤੋਂ ਵਧੀਆ ਸੁਰੱਖਿਆ ਅਭਿਆਸ ਗੈਰ-ਐਨਕ੍ਰਿਪਟਿਡ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ ਅਧਿਕਾਰ ਪ੍ਰਤੀਕਿਰਿਆਵਾਂ ਭੇਜਣ ਦੀ ਮਨਾਹੀ ਕਰਦੀ ਹੈ। ਇਸ ਵਿੱਚ ਉਹ ਰੀਡਾਇਰੈਕਟ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜੋ ਅਧਿਕਾਰ ਕੋਡ ਜਾਂ ਟੋਕਨ ਕਲਾਇੰਟ ਕੋਲ ਵਾਪਸ ਲਿਜਾਂਦਾ ਹੈ, ਸਿਰਫ਼ ਸ਼ੁਰੂਆਤੀ ਬੇਨਤੀ ਨਹੀਂ।
ਉਹੀ ਮਾਰਗਦਰਸ਼ਨ ਨਿਰਧਾਰਿਤ ਨੇਟਿਵ-ਕਲਾਇੰਟ ਲੂਪਬੈਕ ਮਾਮਲੇ ਤੋਂ ਬਿਨਾਂ HTTP ਰੀਡਾਇਰੈਕਟ URI ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ। ਅੰਦਰੂਨੀ ਹੋਸਟਨਾਮ ਨਵਾਂ ਅਪਵਾਦ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਅਤੇ ਸਿਰਫ਼ VPN ਦੇ ਅੰਦਰ ਹੱਲ ਹੋਣ ਵਾਲਾ DNS ਨਾਮ, ਜੇ ਸਕੀਮ ਇੰਝ ਕਹਿੰਦੀ ਹੈ ਤਾਂ, ਅਜੇ ਵੀ HTTP URL ਹੈ। ਰਜਿਸਟਰਡ URI ਵਿੱਚ ਸਕੀਮ ਦੀ ਜਾਂਚ ਕਰੋ, ਸਿਰਫ਼ ਹੋਸਟਨਾਮ ਦੀ ਨਹੀਂ।
ਸਹੀ HTTPS ਰੀਡਾਇਰੈਕਟ URI ਅਧਿਕਾਰ ਸਰਵਰ 'ਤੇ ਰਜਿਸਟਰ ਕਰੋ ਅਤੇ ਕਲਾਇੰਟ 'ਤੇ ਸਰਟੀਫਿਕੇਟ ਪੁਸ਼ਟੀ ਚਾਲੂ ਰੱਖੋ। HTTPS ਲੋੜ ਨੂੰ ਦਬਾਉਣ ਵਾਲਾ ਵਿਕਾਸ ਸ਼ਾਰਟਕਟ ਅਜਿਹਾ ਪ੍ਰਵਾਹ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਉਸ ਉਤਪਾਦਨ ਸੰਰਚਨਾ ਤੋਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦਾ ਹੈ ਜਿਸਦੀ ਇਸਨੂੰ ਨਕਲ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।
ਟੋਕਨ ਐਂਡਪੌਇੰਟ ਅਤੇ ਬੇਅਰਰ ਟੋਕਨ ਬੇਨਤੀਆਂ
ਟੋਕਨ ਬੇਨਤੀ ਪਹੁੰਚ ਦੇ ਬਦਲੇ ਬਦਲੇ ਜਾ ਸਕਣ ਵਾਲੇ ਪ੍ਰਮਾਣ ਜਾਂ ਕੋਡ ਲੈ ਕੇ ਚੱਲਦੀ ਹੈ। ਅਸੁਰੱਖਿਅਤ ਪੜਾਅ 'ਤੇ ਇਸਨੂੰ ਭੇਜਣਾ ਅਜਿਹੀ ਸਮੱਗਰੀ ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ ਜਿਸ 'ਤੇ ਸਰੋਤ ਸਰਵਰ ਬਾਅਦ ਵਿੱਚ ਭਰੋਸਾ ਕਰੇਗਾ, ਭਾਵੇਂ ਆਲੇ-ਦੁਆਲੇ ਦਾ ਨੈੱਟਵਰਕ ਨਿੱਜੀ ਹੋਵੇ। ਜੋ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ ਪੜ੍ਹ ਸਕਦੀ ਹੈ ਉਹ ਇਸਦੇ ਦੁਆਰਾ ਲਿਜਾਏ ਪ੍ਰਮਾਣ ਵੀ ਪੜ੍ਹ ਸਕਦੀ ਹੈ।
ਬੇਅਰਰ ਟੋਕਨ ਵਾਲੀਆਂ ਸਰੋਤ ਬੇਨਤੀਆਂ ਲਈ RFC 6750 ਉਸ ਵਿਸ਼ੇਸ਼ਤਾ ਲਈ TLS ਨੂੰ ਲਾਗੂ ਕਰਨ ਅਤੇ ਵਰਤਣ ਲਈ ਲਾਜ਼ਮੀ ਮੰਨਦਾ ਹੈ। ਦਫ਼ਤਰ ਸਬਨੈੱਟ ਨੂੰ ਭਰੋਸੇਯੋਗ ਕਹਿਣਾ ਉਹ ਆਮ ਪ੍ਰੋਟੋਕੋਲ ਅਪਵਾਦ ਨਹੀਂ ਹੈ ਜੋ ਸਾਦੇ ਟੈਕਸਟ ਬੇਅਰਰ ਤੈਨਾਤੀ ਨੂੰ ਲੋੜੀਂਦਾ ਹੁੰਦਾ ਹੈ।
ਦੋਵੇਂ ਪੜਾਵਾਂ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਸੁਰੱਖਿਅਤ ਐਂਡਪੌਇੰਟ URL ਵਰਤੋ। ਜੇ ਲਾਇਬ੍ਰੇਰੀ HTTP ਟੋਕਨ ਐਂਡਪੌਇੰਟ ਕਾਲ ਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਉਹ ਇਨਕਾਰ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਕੰਮ ਕਰਨਾ ਹੈ, ਟਾਲਣਯੋਗ ਸੰਰਚਨਾ ਦੋਸ਼ ਨਹੀਂ। ਉਹ URL ਰਨਟਾਈਮ 'ਤੇ ਕੱਢਣ ਦੀ ਬਜਾਏ ਕਲਾਇੰਟ ਸੰਰਚਨਾ ਵਿੱਚ ਦਰਜ ਕਰੋ।
TLS ਕਿੱਥੇ ਸਮਾਪਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਇਹ ਕੀ ਛੱਡਦਾ ਹੈ
ਜੇ TLS ਕਿਸੇ ਅਧਿਕ੍ਰਿਤ ਫਰੰਟਐਂਡ 'ਤੇ ਸਮਾਪਤ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਉਸ ਫਰੰਟਐਂਡ ਦਾ ਨਾਮ ਲਓ ਅਤੇ ਉੱਥੋਂ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਦਾ ਮਾਰਗ ਸਮੀਖਿਆ ਕਰੋ। ਫਰੰਟਐਂਡ ਬਾਕੀ ਹਿੱਸੇ 'ਤੇ ਅੱਗੇ ਭੇਜਣ, ਭਰੋਸੇ ਅਤੇ ਗੋਪਨੀਯਤਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਸੇਵਾ ਦੀ ਸਮਰਥਿਤ ਢਾਂਚਾ ਉਸ ਵਿਵਸਥਾ ਦਾ ਵਰਣਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
ਮਾਰਗ ਵਿੱਚ ਕਿਤੇ ਹੋਰ VPN ਉਹ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਤੈਅ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਤੁਹਾਨੂੰ ਇਹ ਵੀ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਬ੍ਰਾਊਜ਼ਰ ਜੋ ਐਪਲੀਕੇਸ਼ਨ URL ਵੇਖਦਾ ਹੈ ਉਹ ਫਰੰਟਐਂਡ ਵੱਲੋਂ ਪੇਸ਼ ਕੀਤੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਜਾਂ ਨਹੀਂ।
ਅੰਦਰੂਨੀ ਤੈਨਾਤੀ ਲਈ, ਸਮਾਪਤੀ ਬਿੰਦੂ ਅਤੇ ਇਹ ਜੋ ਪਛਾਣ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਦਰਜ ਕਰੋ। ਜੋ ਫਰੰਟਐਂਡ ਕਿਸੇ ਹੋਰ ਨਾਮ ਦੇ ਸਰਟੀਫਿਕੇਟ ਨਾਲ TLS ਸਮਾਪਤ ਕਰਦਾ ਹੈ ਉਹ ਬ੍ਰਾਊਜ਼ਰ ਚੇਤਾਵਨੀ ਬਣਾਉਂਦਾ ਹੈ ਜਿਸਨੂੰ ਆਪਰੇਟਰ ਅਕਸਰ ਠੀਕ ਕਰਨ ਦੀ ਬਜਾਏ ਦਬਾ ਦਿੰਦੇ ਹਨ।
ਨੇਟਿਵ ਲੂਪਬੈਕ ਅਪਵਾਦ ਸੰਕੀਰਣ ਹੈ
ਲੂਪਬੈਕ ਰੀਡਾਇਰੈਕਟ ਅਪਵਾਦ ਵਰਤੋਂਕਾਰ ਦੇ ਆਪਣੇ ਡਿਵਾਈਸ 'ਤੇ ਹੋਣ ਵਾਲੇ ਕਾਲਬੈਕ ਬਾਰੇ ਹੈ, ਜਿੱਥੇ ਕਲਾਇੰਟ ਅਤੇ ਬ੍ਰਾਊਜ਼ਰ ਉਹ ਡਿਵਾਈਸ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। ਉਹ ਵਿਵਸਥਾ ਇੱਕ ਡਿਵਾਈਸ ਦੇ ਕਾਲਬੈਕ ਦੀ ਹੈ, ਅਤੇ ਇਹ ਦਫ਼ਤਰ ਸਬਨੈੱਟ ਨੂੰ HTTP ਰਾਹੀਂ ਆਮ ਅਧਿਕਾਰ ਸਰਵਰ ਜਾਂ ਟੋਕਨ ਲਿਜਾਣ ਵਾਲੀ API ਪਰੋਸਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੀ।
ਅਪਵਾਦ ਨੂੰ ਕਲਾਇੰਟ ਕਿਸਮ ਅਤੇ ਉਸ ਕਾਲਬੈਕ ਤੱਕ ਸੀਮਿਤ ਰੱਖੋ ਜਿਸਦਾ ਇਹ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ, ਸਾਂਝੀ ਅੰਦਰੂਨੀ ਸੇਵਾ ਜਾਂ ਕਿਸੇ ਹੋਰ ਹੋਸਟ 'ਤੇ ਰੀਡਾਇਰੈਕਟ URI 'ਤੇ ਲਾਗੂ ਕਰਨਾ ਤੈਨਾਤੀ ਬਦਲਦਾ ਹੈ, ਅਪਵਾਦ ਨਹੀਂ।
ਹਰ ਹੱਦ 'ਤੇ ਅਸਲ ਪ੍ਰਵਾਹ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ ਕਲਾਇੰਟ ਕਿਸਮ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਕੰਮ ਕਰਦਾ ਰੀਡਾਇਰੈਕਟ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ ਕਿ ਟੋਕਨ ਲਿਜਾਣ ਵਾਲੇ ਹਰ ਪੜਾਅ ਨੇ ਲੋੜੀਂਦੀ ਸੁਰੱਖਿਆ ਵਰਤੀ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਹਰਾ VPN ਚਿੰਨ੍ਹ ਅਗਲੀ ਬੇਨਤੀ ਦੀ ਸਕੀਮ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ।