API அங்கீகாரம் (Authentication): API Keys vs JWT vs OAuth 2.0

நான் ஒருமுறை அங்கீகாரம் (authentication) இல்லாத ஒரு API-ஐ வெளியிட்டேன். அது ஒரு எளிய உள் கருவி (internal tool) என்று நான் நினைத்தேன். இரண்டு வாரங்களுக்குப் பிறகு, ஒரு போட்டியாளரின் பாட் (bot) அதிகாலை 3 மணிக்கு எங்கள் தரவுத்தளத்தை (database) ஸ்கிராப் (scrape) செய்தது. அந்தத் தவறு எனக்கு $1,200 AWS கட்டணத்தையும், எனது மேலாளருடன் ஒரு சங்கடமான உரையாடலையும் ஏற்படுத்தியது.

அங்கீகாரம் (Authentication) என்பது சுவாரஸ்யமான விஷயம் அல்ல. ஆனால் நீங்கள் அதைத் தவறாகச் செய்தால், அது அதிகாலை 3 மணிக்கு ஒரு எச்சரிக்கையுடன் (alert) உங்களைத் தூக்கத்திலிருந்து எழுப்பும்.

இந்த மூன்று முக்கிய முறைகளுக்கிடையே எதைத் தேர்ந்தெடுப்பது என்பதற்கான வழிமுறை இதோ.

  • API Keys இவை நீண்ட சீரற்ற சரங்கள் (random strings). கிளையண்ட் ஒவ்வொரு கோரிக்கையுடனும் (request) இவற்றை அனுப்புகிறது. இவை எளிமையானவை மற்றும் வேகமானவை.

இவற்றை எப்போது பயன்படுத்தலாம்: • வானிலை அல்லது பங்குச் சந்தை தரவு போன்ற பொதுவான (Public) APIs. • சர்வர் முதல் சர்வர் வரையிலான தகவல் தொடர்பு (Server to server communication). • ஒரு புதிய யோசனையை முன்மாதிரியாக (Prototyping) உருவாக்குதல். • உள் மைக்ரோசர்வீஸ்கள் (Internal microservices).

  • JWT (JSON Web Tokens) இவை கையொப்பமிடப்பட்ட டோக்கன்கள் (signed tokens). இவை டோக்கனுக்குள்ளேயே பயனர் தகவல் மற்றும் அனுமதிகளைக் கொண்டுள்ளன. அவற்றைச் சரிபார்க்க உங்களுக்குத் தரவுத்தளத் தேடல் (database lookup) தேவையில்லை.

இவற்றை எப்போது பயன்படுத்தலாம்: • ஒவ்வொரு சேவையும் தன்னைத்தானே சரிபார்க்கும் மைக்ரோசர்வீஸ்கள். • மொபைல் செயலிகள் மற்றும் சிங்கிள் பேஜ் அப்ளிகேஷன்கள் (single page applications). • அளவிடப்பட வேண்டிய (scale) அதிகப் போக்குவரத்து கொண்ட APIs.

எச்சரிக்கை: JWT-இல் அதிகப்படியான தரவைச் சேர்க்க வேண்டாம். அதைச் சிறியதாக வைத்திருங்கள். பயனர் ஐடி (user ID) மற்றும் பாத்திரங்களை (roles) மட்டும் சேர்க்கவும்.

  • OAuth 2.0 இது அதிகாரப் பகிர்வுக்கான (delegation) ஒரு நெறிமுறை (protocol) ஆகும். இது கடவுச்சொல்லைப் பகிராமல் ஒரு பயனர் தனது தரவை அணுக அனுமதிப்பதாகும். "Sign in with Google" என்பதைப் போல நினைத்துக் கொள்ளுங்கள்.

இதை எப்போது பயன்படுத்தலாம்: • மூன்றாம் தரப்பு ஒருங்கிணைப்புகள் (Third party integrations). • பயனர்கள் வெவ்வேறு செயலிகளுக்கு குறிப்பிட்ட அனுமதிகளை வழங்கும் அமைப்புகள். • நிறுவன மென்பொருள்கள் (Enterprise software).

இதைத் தவிர்க்க வேண்டியவை: • எளிய உள் API-கள். • விரைவாகச் செயல்பட வேண்டிய சிறிய குழுக்கள்.

விரைவான முடிவு வழிகாட்டி:

• பொது API: API Keys-ஐப் பயன்படுத்தவும். • உள் மைக்ரோசர்வீஸ்கள்: API Keys-ஐப் பயன்படுத்தவும். • மொபைல் ஆப் பேக்எண்ட்: JWT-ஐப் பயன்படுத்தவும். • பயனர் பாத்திரங்களுடன் கூடிய SaaS: JWT-ஐப் பயன்படுத்தவும். • மூன்றாம் தரப்பு அணுகல்: OAuth 2.0-ஐப் பயன்படுத்தவும்.

எனது அடிப்படை விதி:

  1. உள் சேவைகளுக்கு API Keys-உடன் தொடங்கவும்.
  2. பயனர் அங்கீகாரம் தேவைப்படும்போது JWT-ஐச் சேர்க்கவும்.
  3. ஒரு கிளையண்ட் கேட்கும்போதோ அல்லது நீங்கள் ஒரு தளத்தை (platform) உருவாக்கும்போதோ மட்டும் OAuth 2.0-ஐப் பயன்படுத்தவும்.

ஒருபோதும் வெளியிட முடியாத ஒரு முழுமையான அமைப்பை உருவாக்காதீர்கள். செயல்படக்கூடிய ஒரு பாதுகாப்பான அமைப்பை உருவாக்குங்கள்.

நீங்கள் எந்த அங்கீகார முறையைப் பயன்படுத்துகிறீர்கள்? கருத்துகளில் (comments) என்னிடம் சொல்லுங்கள்.

Source: https://dev.to/sirmax/api-authentication-in-2026-api-keys-vs-jwt-vs-oauth-20-when-to-use-what-h7c