Ověřovací systémy jsou základem mnoha webových stránek. Umožňují uživatelům přihlašovat se k webu a zachovávat data mezi jednotlivými návštěvami. Má zásadní význam pro nabídku robustního uživatelského prostředí, které odměňuje vaše uživatele za poskytnutí jejich údajů. Ověřování často poskytuje přístup k osobním soukromým údajům, které by v případě zveřejnění mohly poškodit vašeho uživatele. Aby se jim zabránilo, byly vytvořeny ověřovací protokoly, které zabezpečují požadavky a zároveň umožňují uživatelům stále se bezpečně přihlásit do vašeho systému z jakéhokoli prostředí.

Základní ověřování SSL

Základní ověřování je nejjednodušší formou webového ověřování. Využívá standardní hlavičky HTTP namísto složitějších řešení, která se spoléhají na soubory cookie, identifikátory relace a přihlašovací stránky. V systému základní autentizace je zabudováno jen velmi málo zabezpečení. Pověření jsou přenášena pouze v kódování Base64 a nejsou šifrována ani zaheslována. Vzhledem k zakořeněnému nezabezpečení systému se tyto požadavky nejčastěji provádějí prostřednictvím protokolu HTTPS.

Outorizační informace by měly být sestaveny do následujícího formátu a zahrnuty do hlavičky:

Formát:

<!--Authorization: Basic -->

Úplné informace o protokolu základního ověřování naleznete zde: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth funguje podobně jako základní ověřování SSL s tím rozdílem, že heslo je šifrováno pomocí jednosměrného hashe. Využívá kryptografické hashování MD5 s nonce(hodnotou generovanou serverem, která zabraňuje útokům typu replay).

Typický průběh požadavku Digest Auth je následující :

1. Uživatel přejde na stránku, která vyžaduje ověření uživatele.
2. Server odpoví zprávou 401, která znamená, že uživatel není v současné době oprávněn k přístupu k obsahu. V odpovědi také obsahuje nonce, která bude použita při autorizaci, aby se zabránilo replay útokům,
3. Stránka poté zobrazí autentizační rozhraní, aby shromáždila požadované údaje( uživatelské jméno a heslo )
4. Poskytnuté údaje jsou znovu zaslány serveru s autentizační hlavičkou zahrnutou v požadavku, který má kód odpovědi.
5. Server poté ověří poskytnuté pověření a přijme ověření nebo vrátí zprávu 401, pokud jsou pověření nesprávná, což způsobí, že je uživatel znovu vyzván k zobrazení ověřovacího rozhraní.

Úplné informace o protokolu Digest Auth naleznete zde: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

Protokol OAuth 1.0 je založen na sdíleném tajemství mezi serverem a webem. Toto sdílené tajemství se používá k vygenerování podpisu, který je součástí požadavku. Vygenerovaný podpis se používá k ověření platnosti požadavku na ověření na straně serveru. Proces autorizace uživatele je obecně zpracován ve třech krocích( třístupňový OAuth):

1. Stránka získá token žádosti.
2. Uživatel autorizuje token žádosti.
3. Stránka vymění token žádosti za přístupový token.

Proces dokončení třístupňového požadavku OAuth bude obecně probíhat takto:

1. Stránka odešle podepsanou žádost o Request token. Tento požadavek by měl obsahovat následující parametry:

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

   .

   7. oauth_callback

Tento požadavek bude ověřen na serveru a pokud bude potvrzen, vrátí token požadavku v následujícím formátu:

1. oauth_token
2. oauth_token_secret
3. a případné další parametry vrácené serverem.
4. Dalším krokem po načtení tokenu požadavku je vyzvat uživatele k zadání přihlašovacích údajů. Ty jsou poté zformátovány do podpisu s tokenem požadavku oauth_token a odeslány s požadavkem zpět na server k ověření. Po úspěšném ověření z tohoto požadavku server vrátí následující:
5. oauth_token
6. oauth_verifier

Ty budou použity v dalším kroku k získání přístupového tokenu.

1. Závěrečným krokem je výměna získaných údajů z kroku 2 za přístupový token , který bude použit k přístupu ke zdrojům serveru. Výměna tokenu požadavku za přístupový token, můžete na server podat požadavek s následující podepsanou žádostí
2. oauth_token -vrácený z kroku 2
3. oauth_consumer_key
4. oauth_nonce
5. oauth_signature
6. oauth_signature_method
7. oauth_version
8. oauth_verifier -.vrácený z kroku 2

Vrátí vám přístupový token, který použijete ve spojení s vaším tajemstvím k provádění požadavků na informace ze serveru.

Úplné informace o protokolu OAuth 1.0 najdete zde: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Tento protokol je podobný protokolu OAuth 1.0, při formátování požadavku se spoléhá na identifikační číslo klienta a jeho tajemství, ale zjednodušuje velkou část složitého procesu podepisování, který je vlastní systému OAuth 1.0. Proces autorizace uživatele pomocí třístupňového protokolu OAuth 2.0 je následující:

1. Uživatel je přesměrován na službu pro autorizaci, přičemž v autorizační adrese URL jsou uvedeny následující údaje:

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

2. Uživatel by se pak ověřil u služby a udělil by aplikaci přístup ke svým údajům. Po úspěšném ověření je uživatel přesměrován zpět na redirect_uri s následujícími parametry:

   1. kód
   2. stav

3. Kód vrácený v kroku 2 pak aplikace použije k žádosti o přístupový token. Součástí tohoto požadavku by mělo být:

   1. client_id
   2. client_secret
   3. kód
   4. redirect_uri
   5. grant_type – Ten by měl být nastaven na „authorization_code“

Server tyto údaje ověří a poté vrátí přístupový token s dobou platnosti, pokud jsou platné. Ty jsou obvykle vráceny v následujícím formátu:

1. access_token
2. expires_in
3. refresh_token

Úplné informace o protokolu OAuth 2.0 najdete zde: http://oauth.net/2/

Ověřovací protokoly umožňují zabezpečit data různou úrovní zabezpečení. V závislosti na datech, ke kterým přistupujete, a požadované úrovni zabezpečení vám implementace jednoho z výše uvedených protokolů umožní mít jistotu, že jsou vaše data v bezpečí a že k nim přistupují pouze uživatelé, kteří mají k vašemu systému povolení.