OAuth ene de VPN: kiuj segmentoj ankoraŭ postulas TLS
VPN ŝanĝas, kiu atingas servilon, ne kiel vojaĝas OAuth-mesaĝoj. Decidu laŭ segmento: rajtiga respondo, ĵetona peto kaj portanta alvoko.
Privata enkursigado decidas, kiu atingas la servilon; la transportaj reguloj de OAuth decidas, kiel vojaĝas ĉiu mesaĝo. Retumilo, rajtiga servilo, ĵetona finpunkto kaj risurca servilo povas ĉiuj sidi malantaŭ la sama VPN kaj tamen interŝanĝi mesaĝojn laŭ malsamaj segmentoj. Ĉiu segmento havas sian propran transportan postulon, kaj la VPN malstreĉas neniun el ili. La limo de la VPN kaj la limo de la protokolo estas du malsamaj linioj.
La decido estas pli facila se vi ĉesas demandi, ĉu la reto estas fidinda, kaj komencas demandi, kiu interŝanĝo transiras kiun limon.
Decidu laŭ segmento, ne laŭ reto
Skribu la finpunktojn aparte: rajtiga finpunkto, ĵetona finpunkto, alidirekta URI, URL de la risurca servilo, TLS-finpunkto kaj VPN-pordego. Poste marku, kiu partio komencas ĉiun peton kaj kien iras la respondo.
VPN, kiu finiĝas ĉe pordego, ĉifras la segmenton ĝis tiu pordego. La peto povas daŭri kiel ordinara HTTP malantaŭ ĝi, kaj tiu restanta segmento ne fariĝis HTTPS ĉar pli frua segmento estis ĉifrita. Ĝuste tiu daŭrigo estas la segmento, pri kiu zorgas la protokolo. Ĉifri la unuan salton ne faras la duan salton sekura.
La transporto ankaŭ portas kontrolon de la servo-identeco. La retumilo validigas la atestilon por la URL de la aplikaĵo; VPN ne plenumas tiun validigon anstataŭ la retumilo, kaj ĝi ne faras nevalidigitan finpunkton akceptebla. La atestilo nomas la finpunkton, kiun la kliento kredas voki. Tunelo al pordego ne renomas tiun finpunkton nek validigas ĝin.
La rajtiga respondo kaj la alidirekta URI
La nuna plej bona sekureca praktiko de OAuth malpermesas transdoni rajtigajn respondojn per neĉifritaj konektoj. Tio kovras la alidirekton, kiu portas la rajtigan kodon aŭ la ĵetonojn reen al la kliento, ne nur la komencan peton.
La sama gvidilo malpermesas HTTP-alidirektajn URI-ojn, krom la specifita kazo de loopback por denaskaj klientoj. Interna gastigantnomo ne kreas novan escepton, kaj DNS-nomo, kiu solviĝas nur ene de la VPN, restas HTTP-URL se la skemo tion diras. Kontrolu la skemon en la registrita URI, ne nur la gastigantnomon.
Registru la ĝustan HTTPS-alidirektan URI ĉe la rajtiga servilo kaj tenu atestilan validigon ŝaltita en la kliento. Evolua mallongigo, kiu subpremas la HTTPS-postulon, produktas fluon, kiu kondutas alie ol la produktada agordo, kiun ĝi devus modeligi.
La ĵetona finpunkto kaj petoj kun portanta ĵetono
La ĵetona peto portas akreditaĵojn aŭ kodon, kiun oni povas interŝanĝi kontraŭ aliro. Sendi ĝin laŭ neprotektita segmento elmetas materialon, kiun la risurca servilo poste fidos, eĉ se la ĉirkaŭa reto estas privata. Prokura servilo, kiu povas legi la peton, povas ankaŭ legi la akreditaĵon, kiun ĝi portas.
Por risurcaj petoj kun portanta ĵetono, RFC 6750 traktas TLS kiel devigan por efektivigi kaj uzi laŭ tiu specifikaĵo. Nomi la oficejan subreton fidinda ne estas la ĝenerala protokola escepto, kiun bezonas senkripta portanta deplojo.
Uzu la dokumentitajn sekurajn finpunktajn URL-ojn por ambaŭ segmentoj. Se biblioteko rifuzas voki HTTP-ĵetonan finpunkton, tiu rifuzo estas la specifikaĵo funkcianta, ne agorda cimo por preterpasi. Registru tiun URL en la klienta agordo anstataŭ devenigi ĝin dum rulado.
Kie TLS finiĝas kaj kion tio lasas
Se TLS finiĝas ĉe rajtigita frontaĵo, nomu tiun frontaĵon kaj reviziu la vojon de ĝi al la aplikaĵo. La frontaĵo respondecos pri plusendado, fido kaj konfidenceco en la restanta segmento, kaj la subtenata arkitekturo de la servo devus priskribi tiun aranĝon.
VPN aliloke en la vojo ne solvas tiujn respondecojn. Ĝi ankaŭ ne diras al vi, ĉu la aplikaĵa URL, kiun la retumilo vidas, kongruas kun la atestilo, kiun la frontaĵo prezentas.
Por interna deplojo, registru la finpunkton kaj la identecon, kiun ĝi prezentas. Frontaĵo, kiu finas TLS per atestilo por alia nomo, kreas retumilan averton, kiun operatoroj ofte subpremas anstataŭ ripari.
La escepto de denaska loopback estas mallarĝa
La escepto de loopback-alidirekto koncernas revokon sur la propra aparato de la uzanto, kie la kliento kaj la retumilo dividas tiun aparaton. Tiu aranĝo apartenas al revoko sur unu aparato, kaj ĝi ne rajtigas servi ordinaran rajtigan servilon aŭ API-on kun ĵetonoj per HTTP al oficeja subreto.
Tenu la escepton limigita al la klienta tipo kaj al la revoko, kiun ĝi priskribas. Apliki ĝin al reta aplikaĵo, al komuna interna servo aŭ al alidirekta URI sur alia gastiganto ŝanĝas la deplojon, ne la escepton.
Testu la faktan fluon ĉe ĉiu limo kaj komparu ĝin kun la klienta tipo. Funkcianta alidirekto diras nenion pri tio, ĉu ĉiu segmento, kiu portis ĵetonon, uzis la postulatan protekton, kaj verda VPN-ikono diras nenion pri la skemo de la sekva peto.