Saml vs. OAuth

Saml I OAuth to standardy techniczne upoważnienia użytkowników. Standardy te są używane przez programistów aplikacji internetowych, specjalistów ds. Bezpieczeństwa i administratorów systemów, którzy chcą ulepszyć swoją usługę zarządzania tożsamością i ulepszyć metody, w których klienci mogą uzyskać dostęp do zasobów za pomocą zestawu poświadczeń. W przypadkach, gdy potrzebny jest dostęp do aplikacji z portalu, istnieje potrzeba scentralizowanego źródła tożsamości lub pojedynczego znaku. W takich przypadkach SAML jest preferowany. W przypadkach, w których potrzebny jest tymczasowy dostęp do zasobów, takich jak konta lub pliki, OAuth jest uważany za lepszy wybór. W przypadkach użycia mobilnego OAuth jest najczęściej używany. Zarówno SAML (Assertion and Manuk Language), jak i OAuth (otwarte autoryzacja) są używane do pojedynczego logowania internetowego, zapewniając opcję pojedynczej rejestracji dla wielu aplikacji internetowych.

Saml

Saml Służy do umożliwienia dostawcom SSO aplikacji internetowych na przesyłanie i przenoszenie poświadczeń między dostawcą tożsamości (IDP), który zawiera poświadczenia, a usługodawcą (SP), który jest zasobem potrzebującym tych poświadczeń. Saml to standardowy język protokołu autoryzacji i uwierzytelniania, który jest najczęściej używany do wykonywania federacji i zarządzania tożsamością, wraz z pojedynczym znakiem zarządzania. W Saml, Dokumenty metadanych XML są używane jako token do przesłania tożsamości klienta. Proces uwierzytelnienia i autoryzacji Saml następująco:

1. Użytkownik żąda zalogowania się do usługi za pośrednictwem przeglądarki.
2. Usługa informuje przeglądarkę, że uwierzytelnia się z określonym dostawcą tożsamości (IDP) zarejestrowanego w usłudze.
3. Przeglądarka przekazuje żądanie uwierzytelnienia zarejestrowanym dostawcom tożsamości w celu logowania i uwierzytelniania.
4. Po pomyślnej kontroli poświadczenia/uwierzytelniania IDP generuje dokument oświadczenia oparty na XML, weryfikujący tożsamość użytkownika i przekazuje to przeglądarce.
5. Przeglądarka przekazuje twierdzenie dla usługodawcy.
6. Dostawca usług (SP) przyjmuje twierdzenie o wprowadzeniu i umożliwia użytkownikowi dostęp do usługi, logując się.

Teraz spójrzmy na prawdziwy przykład. Załóżmy, że użytkownik kliknie Zaloguj sie Opcja usługi udostępniania obrazu na stronie internetowej ABC.com. Aby uwierzytelnić użytkownika, ABC zaszyfrowane jest żądanie uwierzytelniania SAML.com. Żądanie zostanie wysłane ze strony internetowej bezpośrednio do serwera autoryzacji (IDP). Tutaj usługodawca przekieruje użytkownika do IDP w celu uzyskania autoryzacji. IDP zweryfikuje otrzymane żądanie uwierzytelniania SAML, a jeśli żądanie okaże się poprawne, przedstawi użytkownikowi formularz logowania do wprowadzenia poświadczeń. Po wejściu użytkownika do poświadczeń IDP wygeneruje SAML Aserertion lub Token SAML zawierający dane i tożsamość użytkownika i wyśle ​​je do usługodawcy. Dostawca usług (SP) weryfikuje twierdzenie SAML i wyodrębnia dane i tożsamość użytkownika, przypisuje prawidłowe uprawnienia do użytkownika i rejestruje użytkownika do usługi.

Twórcy aplikacji internetowych mogą korzystać z wtyczek SAML, aby zapewnić, że aplikacja i zasoby są zgodne z potrzebnym pojedynczym znakiem w praktykach. Sprawi to lepsze wrażenia logowania użytkowników i bardziej skuteczne praktyki bezpieczeństwa, które wykorzystują wspólną strategię tożsamości. Z SAML na miejscu, tylko użytkownicy o prawidłowej tożsamości i tokena oświadczenia mogą uzyskać dostęp do zasobów.

OAuth

OAuth jest używany, gdy istnieje potrzeba uchwalenia autoryzacji z jednej usługi do innej usługi bez udostępniania rzeczywistych poświadczeń, takich jak hasło i nazwa użytkownika. Za pomocą OAuth, Użytkownicy mogą zalogować się do jednej usługi, uzyskać dostęp do zasobów innych usług i wykonywać działania w usłudze. OAuth to najlepsza metoda wykorzystywana do przekazywania autoryzacji z jednego znaku na platformie do innej usługi lub platformy lub między dowolnymi dwoma aplikacjami internetowymi. OAuth przepływ pracy jest następujący:

1. Użytkownik kliknie przycisk logowania usługi udostępniania zasobów.
2. Serwer zasobów pokazuje użytkownikowi dotację autoryzacji i przekierowuje użytkownika na serwer autoryzacji.
3. Użytkownik żąda tokenu dostępu z serwera autoryzacji za pomocą kodu dotacji autoryzacji.
4. Jeśli kod jest prawidłowy po zalogowaniu się do serwera autoryzacji, użytkownik otrzyma token dostępu, którego można użyć do pobierania lub dostępu do chronionego zasobu z serwera zasobów.
5. Po otrzymaniu żądania zasobu chronionego za pomocą tokena dotacji dostępu, ważność tokena dostępu jest sprawdzana przez serwer zasobów za pomocą serwera autoryzacji.
6. Jeśli token jest ważny i przekazuje wszystkie czeki, zasób chroniony jest przyznawany przez serwer zasobów.

Jednym z powszechnych zastosowań OAuth jest umożliwienie aplikacji internetowej dostępu do platformy mediów społecznościowych lub innego konta online. Konta użytkowników Google mogą być używane z wieloma aplikacjami konsumenckimi z kilku różnych powodów, takich jak blogowanie, gry online, logowanie się z kontami mediów społecznościowych i czytanie artykułów na stronach z wiadomościami. W takich przypadkach OAuth działa w tle, aby te podmioty zewnętrzne mogły być połączone i uzyskać dostęp do niezbędnych danych.

OAuth jest koniecznością, ponieważ musi istnieć sposób wysyłania informacji o autoryzacji między różnymi aplikacjami bez udostępniania lub ujawniania poświadczeń użytkowników. OAuth jest również używany w firmach. Załóżmy na przykład, że użytkownik musi uzyskać dostęp do pojedynczego znaku firmy w systemie za pomocą nazwy użytkownika i hasła. SSO zapewnia mu dostęp do wszystkich potrzebnych zasobów, przekazując tokeny autoryzacji OAuth do tych aplikacji lub zasobów.

Wniosek

OAuth i SAML są bardzo ważne z punktu widzenia programisty aplikacji internetowych lub administratora systemu, podczas gdy oba są bardzo różnymi narzędziami z różnymi funkcjami. OAuth to protokół autoryzacji dostępu, podczas gdy SAML jest drugim miejscem, które analizuje dane wejściowe i zapewnia autoryzację użytkownikowi.