𝗧𝗵𝗲 𝗢𝗽𝗲𝗻𝗜𝗗 𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 𝗙𝗶𝘅 𝗙𝗼𝗿 𝗠𝗖𝗣 𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗼𝗿𝘀
ഒരു റിമോട്ട് MCP കണക്ടർ ശരിയാക്കാൻ ഈ ആഴ്ച ഞാൻ ഒരുപാട് സമയം ചെലവഴിച്ചു.
എന്റെ OAuth സെർവർ കണ്ടെത്താൻ കണക്ടർ പരാജയപ്പെട്ടുകൊണ്ടിരുന്നു. സെർവർ കൃത്യമായി പ്രവർത്തിക്കുന്നുണ്ടായിരുന്നു. ഒരു റൂട്ട് (route) വിട്ടുപോയതും ഒരു റീഡയറക്റ്റും (redirect) ആയിരുന്നു പ്രശ്നം.
നിങ്ങൾ MCP-യോടൊപ്പം OAuth ഉപയോഗിക്കുമ്പോൾ, ഡിസ്കവറി ഡോക്യുമെന്റുകൾ (discovery documents) പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾ പ്രതീക്ഷിക്കുന്നു. മിക്ക ടൂളുകളും ഈ രണ്ട് പാത്തുകൾ (paths) ആണ് തിരയുന്നത്:
- /.well-known/oauth-authorization-server
- /.well-known/oauth-protected-resource
ഓതറൈസേഷൻ (authorization), ടോക്കൺ എൻഡ്പോയിന്റുകൾ (token endpoints) എന്നിവ എവിടെ കണ്ടെത്താം എന്ന് ഇവ ക്ലയന്റുകളെ അറിയിക്കുന്നു.
പ്രശ്നം എന്തെന്നാൽ, പല ക്ലയന്റുകളും ആ പ്രത്യേക പാത്തുകൾ തിരയുന്നില്ല എന്നതാണ്. പകരം, അവർ /.well-known/openid-configuration ആണ് തിരയുന്നത്.
ഇതൊരു OpenID Connect പാത്താണ്. ഇതൊരു വ്യത്യസ്ത സ്പെസിഫിക്കേഷൻ (spec) ആണ്, എങ്കിലും ഇത് ഒരേ സ്ഥലത്ത് തന്നെയാണ് വരുന്നത്. എന്റെ പാക്കേജ് OAuth സ്പെസിഫിക്കേഷൻ ആണ് പിന്തുടരുന്നത്, OIDC സ്പെസിഫിക്കേഷൻ അല്ല, അതിനാൽ ഞാൻ ഈ പാത്ത് രജിസ്റ്റർ ചെയ്തിരുന്നില്ല.
നിലവിലില്ലാത്ത ഒരു വാതിലിൽ ക്ലയന്റ് മുട്ടുന്നു. അതിന് 404 എറർ ലഭിക്കുകയും അത് പ്രവർത്തനം നിർത്തുകയും ചെയ്യുന്നു.
എനിക്ക് രണ്ട് വഴികളുണ്ടായിരുന്നു:
Nginx-ൽ ഒരു റിവേഴ്സ്-പ്രോക്സി റീഡയറക്റ്റ് (reverse-proxy redirect) ഉപയോഗിക്കുക. ഇതൊരു എളുപ്പവഴിയാണ് (lazy fix). ഇത് നിങ്ങളുടെ ലോജിക് കോഡിൽ നിന്ന് ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് മാറ്റുന്നു. ഇത് ടെസ്റ്റ് ചെയ്യാൻ പ്രയാസമാണ്, കൂടാതെ ഡെപ്ലോയ്മെന്റ് സമയത്ത് തെറ്റുകൾ സംഭവിക്കാനും സാധ്യതയുണ്ട്.
ആപ്ലിക്കേഷനുള്ളിൽ തന്നെ ഇത് പരിഹരിക്കുക. ഇതാണ് മികച്ച രീതി.
ആപ്ലിക്കേഷൻ ആ അന്വേഷണത്തിന് (probe) മറുപടി നൽകുന്ന രീതിയാണ് ഞാൻ തിരഞ്ഞെടുത്തത്. OpenID പാത്തിനെ OAuth ഓതറൈസേഷൻ പാത്തിലേക്ക് റീഡയറക്റ്റ് ചെയ്യുന്ന ഒരു ഏലിയാസ് (alias) ഞാൻ നിർമ്മിച്ചു.
ഞാൻ ഒരു 308 Permanent Redirect ആണ് ഉപയോഗിച്ചത്.
ഒരു 302 റീഡയറക്റ്റ് POST റിക്വസ്റ്റിനെ GET റിക്വസ്റ്റാക്കി മാറ്റിയേക്കാം. എന്നാൽ 308 റീഡയറക്റ്റ് കർശനമാണ്. പുതിയ URL-ലേക്ക് പോകാനും അതേ മെത്തേഡും ബോഡിയും (method and body) നിലനിർത്താനും ഇത് ക്ലയന്റിനോട് ആവശ്യപ്പെടുന്നു. ഒരു സ്ഥിരമായ മാറ്റം (permanent move) കൈകാര്യം ചെയ്യാനുള്ള ശരിയായ രീതി ഇതാണ്.
ഞാൻ ഇത് ഒരു കോൺഫിഗറേഷൻ ഫ്ലാഗിന് (configuration flag) പിന്നിലായി സെറ്റ് ചെയ്തു. ഉപയോക്താക്കൾക്ക് അവരുടെ സ്വന്തം OIDC ഡിസ്കവറി ഉപയോഗിക്കുന്നുണ്ടെങ്കിൽ ഇത് ഓഫ് ചെയ്യാൻ ഇത് അനുവദിക്കുന്നു.
കോഡിൽ തന്നെ ഇത് ചെയ്യുന്നതിലൂടെ എനിക്ക് ടെസ്റ്റുകൾ എഴുതാൻ സാധിക്കുന്നു:
- റീഡയറക്റ്റ് ശരിയായി നടക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കാൻ ഒരു ടെസ്റ്റ്.
- മെറ്റാഡാറ്റ (metadata) ശരിയാണെന്ന് ഉറപ്പാക്കാൻ റീഡയറക്റ്റ് പിന്തുടരുന്ന മറ്റൊരു ടെസ്റ്റ്.
ഇത് മെറ്റാഡാറ്റയുടെ ഘടനയിൽ മാറ്റം വന്നാൽ എന്റെ ടെസ്റ്റുകൾ ഉടൻ തന്നെ പരാജയപ്പെടുന്നു എന്ന് ഉറപ്പാക്കുന്നു. ഒരു ഉപയോക്താവിന് കണക്ട് ചെയ്യാൻ കഴിയാത്ത അവസ്ഥ വരാതെ തന്നെ, എന്റെ പൈപ്പ്ലൈനിൽ (pipeline) തന്നെ എനിക്ക് പിശക് കണ്ടെത്താൻ സാധിക്കുന്നു.
പ്രായോഗികമായി സ്പെസിഫിക്കേഷനുകൾ പലപ്പോഴും വ്യത്യാസപ്പെട്ടിരിക്കും. രണ്ട് സ്റ്റാൻഡേർഡുകൾക്ക് സമാനമായ ലക്ഷ്യങ്ങൾ ഉണ്ടെങ്കിൽ പോലും, ക്ലയന്റുകൾ വ്യത്യസ്ത പാത്തുകൾ തിരഞ്ഞെടുക്കാം. ഒരു സെർവർ ഡെവലപ്പർ എന്ന നിലയിൽ, നിങ്ങൾ രണ്ട് വാതിലുകൾക്കും മറുപടി നൽകേണ്ടതുണ്ട്.
അവയെ ഒരേ സ്ഥലത്തേക്ക് എത്തിക്കുക, ശരിയായ റീഡയറക്റ്റ് കോഡ് ഉപയോഗിക്കുക, കൂടാതെ ടെസ്റ്റുകൾ ഉപയോഗിച്ച് അത് ഉറപ്പുവരുത്തുക.
MCP കണക്ടറുകൾ തടസ്സമില്ലാതെ പ്രവർത്തിപ്പിക്കാൻ സഹായിക്കുന്ന 'well-known OpenID configuration' ഏലിയാസ്
MCP (Model Context Protocol) കണക്ടറുകൾ നിർമ്മിക്കുമ്പോൾ നേരിടുന്ന ഏറ്റവും വലിയ വെല്ലുവിളികളിലൊന്ന് ഓതന്റിക്കേഷൻ (authentication) ആണ്. നിങ്ങളുടെ കണക്ടർ ഗൂഗിൾ (Google), മൈക്രോസോഫ്റ്റ് (Microsoft), അല്ലെങ്കിൽ ഒക്റ്റ (Okta) പോലുള്ള വിവിധ ഐഡന്റിറ്റി പ്രൊവൈഡറുകളുമായി (identity providers) സുഗമമായി പ്രവർത്തിക്കണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്നു.
ഓരോ പ്രൊവൈഡറിനും വേണ്ടി ക്ലയന്റ് ഐഡികൾ (client IDs), ക്ലയന്റ് സീക്രട്ടുകൾ (client secrets), ടോക്കൺ എൻഡ്പോയിന്റുകൾ (token endpoints) എന്നിവ മാനുവലായി കോൺഫിഗർ ചെയ്യുന്നത് വലിയൊരു തലവേദനയാണ്.
ഇവിടെയാണ് .well-known/openid-configuration എൻഡ്പോയിന്റ് പ്രസക്തമാകുന്നത്.
ഇത് OpenID Connect (OIDC) സ്പെസിഫിക്കേഷന്റെ ഒരു ഭാഗമാണ്. ഒരു ഐഡന്റിറ്റി പ്രൊവൈഡറു