વપરાશકર્તા “સાઇન ઇન” પર ક્લિક કરે છે, પ્રદાતાના પૃષ્ઠ પર પહોંચે છે અને Rails પર પાછા ફરે છે. આગળનું પગલું હજુ પણ નિષ્ફળ જઈ શકે છે, કારણ કે તે Rails સર્વરથી નવું કનેક્શન શરૂ કરે છે.

browser → provider authorization page → browser callback to Rails
Rails   → provider token endpoint → Rails

બ્રાઉઝર પોતાની નેટવર્ક ગોઠવણી વડે ઓથોરાઇઝેશન રીડાયરેક્ટને અનુસરે છે. Rails ઇન્સ્ટોલ કરેલી OmniAuth વ્યૂહરચના પસંદ કરેલા HTTP ક્લાયન્ટ વડે બેકચેનલ ટોકન એક્સચેન્જ કરે છે. કોર્પોરેટ પ્રોક્સી પાછળ ચાલતા વર્કરને પ્રદાતા તરફની વિનંતીઓમાં તે માર્ગની જરૂર પડે છે.

OAuth 1.0 માં પણ વપરાશકર્તા ઍક્સેસ અધિકૃત કરે તે પહેલાં સર્વર બાજુએ વિનંતી-ટોકનનું પગલું હોય છે. OAuth 2.0 ના ઓથોરાઇઝેશન-કોડ ફ્લોમાં કૉલબેક પછી પોતાનું ટોકન એક્સચેન્જ હોય છે. ચોક્કસ ક્રમ વ્યૂહરચના પર આધાર રાખે છે, પરંતુ બ્રાઉઝર અને એપ્લિકેશન સર્વર અલગ પ્રારંભિક બિંદુઓ રહે છે.

ક્લાયન્ટની ગોઠવણી શોધો

વ્યૂહરચનાને અનુસરીને તે HTTP ક્લાયન્ટ સુધી જાઓ જે તેનું ટોકન અને પ્રદાતાની API વિનંતીઓ મોકલે છે. તે ક્લાયન્ટના દસ્તાવેજીકૃત પ્રોક્સી વિકલ્પનો ઉપયોગ કરો. કેટલીક વ્યૂહરચનાઓ ક્લાયન્ટ વિકલ્પો OAuth લાઇબ્રેરીને પસાર કરે છે; અન્ય તેની નીચે HTTP કનેક્શન ગોઠવે છે. એક વ્યૂહરચના સ્વીકારે તે વિકલ્પ આપમેળે OmniAuthનો સહિયારો વિકલ્પ નથી.

પ્રદાતાના ઓથોરાઇઝેશન, ટોકન અને કૉલબેક URL તેમની વાસ્તવિક સેવાઓનું વર્ણન કરતા રહેવા દો. આઉટબાઉન્ડ પ્રોક્સી પ્રદાતા સુધી પહોંચવા માટેની પરિવહન ગોઠવણી છે, તે કૉલબેક સરનામાનો વિકલ્પ કે OAuth વિનંતીના પરિમાણોમાં ઉમેરવાનું ક્ષેત્ર નથી.

લોગિન ટ્રેસ કરતી વખતે છેલ્લું પૂર્ણ થયેલું પગલું ચિહ્નિત કરો. દર્શાવેલું પ્રદાતા લોગિન પૃષ્ઠ સાબિત કરે છે કે બ્રાઉઝરનો માર્ગ કામ કર્યો. Rails દ્વારા મળેલો કૉલબેક સાબિત કરે છે કે બ્રાઉઝર પાછું આવ્યું. તે પછીની ટોકન વિનંતી એ Rails પ્રક્રિયામાંથી આવતા પ્રોક્સી કનેક્શન, પડકાર અથવા પ્રદાતાના પ્રતિભાવની તપાસ કરવાનું સ્થળ છે.

સંબંધિત લેખો