A hitelesítési rendszerek számos weboldal gerincét képezik. Lehetővé teszi a felhasználók számára a webhelyre való bejelentkezést és az adatok megőrzését a látogatások között. Alapvető fontosságú a robusztus felhasználói élmény biztosításában, amely jutalmazza a felhasználókat az adataik megadásáért. A hitelesítések gyakran hozzáférést biztosítanak személyes magánadatokhoz, amelyek nyilvánosságra kerülése kárt okozhat a felhasználónak. Ezek megelőzésére olyan hitelesítési protokollokat hoztak létre, amelyek biztosítják a kérések biztonságát, ugyanakkor lehetővé teszik, hogy a felhasználók továbbra is biztonságosan bejelentkezhessenek a rendszerébe bármilyen környezetből.

Basic SSL Auth

A basic auth a webes hitelesítés legegyszerűbb formája. A szabványos HTTP fejléceket használja a bonyolultabb, sütikre, munkamenet-azonosítókra és bejelentkezési oldalakra támaszkodó megoldások helyett. Az alap auth rendszerbe nagyon kevés biztonság van beépítve. A hitelesítő adatok csak Base64 kódolással kerülnek továbbításra, és nincsenek titkosítva vagy tördelve. A rendszerben rejlő bizonytalanságok miatt ezek a kérések leggyakrabban HTTPS-en keresztül történnek.

A felhatalmazási információkat a következő formátumban kell összeállítani és a fejlécbe foglalni:

Formátum:

<!--Authorization: Basic -->

Az alapvető hitelesítési protokoll részletes leírása itt található: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth az alap SSL-hitelesítéshez hasonlóan működik, azzal a különbséggel, hogy a jelszó titkosítása egyirányú hash segítségével történik. MD5 kriptográfiai kivonatolást használ egy nonce (egy szerver által generált érték, amely megakadályozza a visszajátszási támadásokat) segítségével.

A Digest Auth kérés tipikus folyamata a következő :

1. A felhasználó egy olyan oldalra navigál, amely a felhasználó hitelesítését igényli.
2. A szerver 401 üzenettel válaszol, amely azt jelzi, hogy a felhasználó jelenleg nem jogosult a tartalom elérésére. A válaszban tartalmazza a nonce-t is, amelyet az engedélyezés során használnak a visszajátszási támadások megelőzésére,
3. Az oldal ezután megjelenít egy hitelesítési felületet a szükséges adatok ( felhasználónév és jelszó )
4. A megadott adatokat a szerver a kérelemben szereplő hitelesítési fejléccel továbbítja, amely egy válaszkódot tartalmaz.
5. A szerver ezután ellenőrzi a megadott hitelesítő adatokat, és elfogadja a hitelesítést, vagy 401 üzenetet küld vissza, ha a hitelesítő adatok helytelenek, ami miatt a felhasználónak újra meg kell jelennie a hitelesítési felületen.

A Digest Auth protokoll teljes részleteit itt találja: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

Az OAuth 1.0 protokoll a szerver és a webhely közötti megosztott titokra támaszkodik. Ez a megosztott titok egy aláírás létrehozására szolgál, amelyet a kérés tartalmaz. A generált aláírást arra használják, hogy a szerveroldalon ellenőrizzék a hitelesítési kérelem érvényességét. A felhasználó engedélyezésének folyamata általában három lépésben történik( 3-lábú OAuth):

1. A webhely megkapja a kérvénytokent.
2. A felhasználó engedélyezi a kérvénytokent.
3. A webhely kicseréli a kérvénytokent hozzáférési tokenre.

A háromlépcsős OAuth-kérelem teljesítésének folyamata általában a következőképpen zajlik:

1. A webhely egy aláírt kérést küld a Request tokenért. Ennek a kérésnek a következő paramétereket kell tartalmaznia:

   1. oauth_consumer_key
   2. oauth_timestamp
   3. oauth_nonce
   4. oauth_signature
   5. oauth_signature_method
   6. oauth_version

   .

   7. oauth_callback

Ezt a kérést a szerver validálja, és ha validált, akkor a következő formátumban adja vissza a kérés tokenjét:

1. oauth_token
2. oauth_token_secret
3. és a szerver által visszaküldött további paramétereket.
4. A kérés tokenjének lekérdezése után a következő lépés az, hogy felszólítsa a felhasználót a bejelentkezési adatok megadására. Ezeket az oauth_token kérési tokennel aláírássá formázza, majd a kéréssel együtt visszaküldi a kiszolgálónak érvényesítésre. A kérés sikeres érvényesítését követően a szerver a következőket küldi vissza:
5. oauth_token
6. oauth_verifier

Ezeket a következő lépésben egy hozzáférési token lekérdezésére használjuk.

1. Az utolsó lépés a 2. lépésben lekérdezett adatok kicserélése egy hozzáférési tokenre , amely a szerver erőforrásainak elérésére szolgál. A kérési token cseréje egy hozzáférési tokenre, a következő aláírt kérelemmel
2. oauth_token -a 2. lépésből visszakapott
3. oauth_consumer_key
4. oauth_nonce
5. oauth_signature
6. oauth_signature_method
7. oauth_version
8. oauth_verifier – kérést küldhet a szervernek.a 2. lépésből visszakapod

Ez egy hozzáférési tokent ad vissza, amelyet a titkoddal együtt használhatsz a szervertől való információkéréshez.

Az OAuth 1.0 protokoll teljes részleteit itt találja: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Ez hasonló az OAuth 1.0 protokollhoz, egy ügyfél azonosítóra és titokra támaszkodik a kérés formázásához, de leegyszerűsíti az OAuth 1.0 rendszerben rejlő bonyolult aláírási folyamat nagy részét. A felhasználó engedélyezésének folyamata a háromlábú OAuth 2.0 protokoll a következő:

1. A felhasználót az engedélyezés céljából a szolgáltatáshoz irányítják, az engedélyezési URL-ben szereplő következő adatokkal:

   1. client_id
   2. redirect_uri
   3. response_type
   4. scope

2. A felhasználó ezután hitelesíti magát a szolgáltatásnál, és hozzáférést biztosít az alkalmazásnak az adataihoz. Sikeres hitelesítés után a felhasználó visszairányításra kerül a redirect_uri-ra a következő paraméterekkel:

   1. code
   2. state

3. A 2. lépésben visszaküldött kódot az alkalmazás a hozzáférési token kérésére használja. Ennek a kérésnek tartalmaznia kell:

   1. client_id
   2. client_secret
   3. code
   4. redirect_uri
   5. grant_type – Ennek “authorization_code”

A szerver ellenőrzi ezeket az adatokat, majd egy lejárati idővel ellátott hozzáférési tokent küld vissza, ha azok érvényesek. Ezeket általában a következő formátumban küldi vissza:

1. access_token
2. expires_in
3. refresh_token

Az OAuth 2.0 protokoll teljes részleteit itt találja: http://oauth.net/2/

A hitelesítési protokollok lehetővé teszik az adatok különböző biztonsági szintekkel történő védelmét. Az elérendő adatoktól és az Ön által kívánt biztonsági szinttől függően a fenti protokollok valamelyikének bevezetésével biztos lehet abban, hogy adatai biztonságban vannak, és csak olyan felhasználók férnek hozzá, akiknek engedélyezve van a rendszerhez való hozzáférésük.