Articles

Protokoły uwierzytelniania stron internetowych

by admin

Systemy uwierzytelniania są kręgosłupem wielu stron internetowych. Pozwalają użytkownikom logować się do Twojej witryny i zachować dane pomiędzy wizytami. Jest to kluczowe w oferowaniu solidnego doświadczenia użytkownika, który nagradza swoich użytkowników za dostarczanie swoich danych. Uwierzytelnianie często zapewnia dostęp do prywatnych danych osobowych, które jeśli zostaną upublicznione, mogą zaszkodzić Twojemu użytkownikowi. Aby temu zapobiec, protokoły uwierzytelniania zostały stworzone w celu zabezpieczenia żądań, jednocześnie pozwalając użytkownikom nadal bezpiecznie logować się do Twojego systemu z dowolnego środowiska.

Podstawowe SSL Auth

Podstawowe auth jest najprostszą formą uwierzytelniania sieciowego. Wykorzystuje standardowe nagłówki HTTP w miejsce bardziej skomplikowanych rozwiązań, które opierają się na ciasteczkach, identyfikatorach sesji i stronach logowania. W podstawowy system autoryzacji wbudowane jest bardzo mało zabezpieczeń. Dane uwierzytelniające są przesyłane tylko w kodowaniu Base64 i nie są szyfrowane ani haszowane. Ze względu na wbudowane zabezpieczenia w systemie, żądania te są najczęściej wykonywane przez HTTPS.

Informacje autoryzacyjne powinny być skompilowane do następującego formatu i zawarte w nagłówku:

Format:

<!--Authorization: Basic -->

Pełne szczegóły na temat protokołu Basic Authentication można znaleźć tutaj: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth działa podobnie do podstawowego uwierzytelniania SSL z tym wyjątkiem, że hasło jest szyfrowane przy użyciu jednokierunkowego hasha. Wykorzystuje on kryptograficzne haszowanie MD5 z nonce (wartość generowana przez serwer, która zapobiega atakom powtórzenia).

Typowy przepływ żądania Digest Auth jest następujący:

  1. Użytkownik przechodzi do strony, która wymaga uwierzytelnienia użytkownika.
  2. Serwer odpowiada komunikatem 401, który oznacza, że użytkownik nie jest obecnie upoważniony do dostępu do zawartości. W odpowiedzi znajduje się również nonce, który będzie używany podczas autoryzacji, aby zapobiec atakom powtórzenia,
  3. Strona następnie wyświetla interfejs uwierzytelniania w celu zebrania wymaganych szczegółów (nazwa użytkownika i hasło).
  4. Dostarczone szczegóły są ponownie wysyłane do serwera z nagłówkiem uwierzytelniania zawartym w żądaniu, które ma kod odpowiedzi.
  5. Serwer następnie zweryfikuje dostarczone dane uwierzytelniające i zaakceptuje uwierzytelnienie lub zwróci wiadomość 401, jeśli dane uwierzytelniające są nieprawidłowe, co spowoduje, że użytkownik zostanie ponownie poproszony o podanie interfejsu uwierzytelniania.

Pełne szczegóły na temat protokołu Digest Auth można znaleźć tutaj: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

Protokół OAuth 1.0 opiera się na posiadaniu współdzielonego sekretu między serwerem a witryną. Ten wspólny sekret jest używany do generowania podpisu, który jest zawarty w żądaniu. Wygenerowany podpis jest używany do weryfikacji po stronie serwera ważności żądania uwierzytelnienia. Proces autoryzacji użytkownika jest zazwyczaj obsługiwany w trzech krokach (3-legged OAuth):

  1. Serwis uzyskuje Request Token.
  2. Użytkownik autoryzuje Request Token.
  3. Serwis wymienia Request Token na Access Token.

Proces wypełniania trójstopniowego żądania OAuth będzie ogólnie obsługiwany w następujący sposób:

  1. Strona wyśle podpisane żądanie o token Request. Żądanie to powinno zawierać następujące parametry:

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

      7. .

    7. oauth_callback

To żądanie zostanie zweryfikowane na serwerze i jeśli zostanie zweryfikowane, zwróci token żądania w następującym formacie:

  1. oauth_token
  2. oauth_token_secret
  3. oraz wszelkie inne dodatkowe parametry zwracane przez Twój serwer.
  4. Kolejnym krokiem po pobraniu tokena żądania jest poproszenie użytkownika o wprowadzenie danych uwierzytelniających do logowania. Są one następnie formatowane do podpisu z tokenem żądania oauth_token i wysyłane z żądaniem z powrotem do serwera w celu sprawdzenia poprawności. Po pomyślnej walidacji tego żądania serwer zwróci następujące dane:
  5. oauth_token
  6. oauth_verifier

Będą one użyte w następnym kroku do pobrania tokena dostępu.

  1. Ostatnim krokiem jest wymiana pobranych danych z kroku 2 na token dostępu, który będzie używany do uzyskania dostępu do zasobów serwera. Aby wymienić swój token żądania na token dostępu, możesz wysłać do serwera żądanie o następującej treści: signed request
  2. oauth_token -returned from step 2
  3. oauth_consumer_key
  4. oauth_nonce
  5. oauth_signature
  6. oauth_signature_method
  7. oauth_version
  8. oauth_verifier -.zwrócony z kroku 2

To zwróci ci token dostępu, który ma być używany w połączeniu z twoim sekretem w celu żądania informacji od serwera.

Pełne szczegóły na temat protokołu OAuth 1.0 można znaleźć tutaj: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Jest on podobny do protokołu OAuth 1.0, polega na id klienta i sekrecie w celu sformatowania żądania, ale upraszcza wiele ze skomplikowanego procesu podpisywania, który jest nieodłączny w systemie OAuth 1.0. Proces autoryzacji użytkownika za pomocą trójstopniowego protokołu OAuth 2.0 jest następujący:

  1. Użytkownik jest kierowany do usługi w celu autoryzacji z następującymi szczegółami zawartymi w autoryzacyjnym adresie URL:

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

  2. Użytkownik następnie uwierzytelnia się w usłudze i przyznaje aplikacji dostęp do swoich danych. Po pomyślnym uwierzytelnieniu użytkownik jest przekierowywany z powrotem do redirect_uri z następującymi parametrami:

    1. code
    2. state

  3. Kod zwrócony w kroku 2 jest następnie wykorzystywany przez aplikację do złożenia wniosku o token dostępu. W tym żądaniu powinny być zawarte:

    1. client_id
    2. client_secret
    3. code
    4. redirect_uri
    5. grant_type – Powinien być ustawiony na „authorization_code”

Serwer zweryfikuje te szczegóły, a następnie zwróci token dostępu z czasem wygaśnięcia, jeśli są one ważne. Są one zazwyczaj zwracane w następującym formacie:

  1. access_token
  2. expires_in
  3. refresh_token

Pełne szczegóły na temat protokołu OAuth 2.0 można znaleźć tutaj: http://oauth.net/2/

Protokoły uwierzytelniania pozwalają na zabezpieczenie danych z różnym poziomem bezpieczeństwa. W zależności od dostępnych danych i pożądanego poziomu bezpieczeństwa, wdrożenie jednego z powyższych protokołów pozwala mieć pewność, że dane są bezpieczne, a dostęp do nich mają tylko użytkownicy, którzy są dopuszczeni do systemu.