OAuth to otwarty standard, który umożliwia użytkownikom zapewnianie witrynom lub aplikacjom delegowanego dostępu do ich informacji przechowywanych w innych witrynach lub aplikacjach bez podawania danych uwierzytelniających (tj. hasła), które umożliwiają bezpośredni dostęp do konta, na którym przechowywane są informacje. Zamiast tego udostępniany jest token dostępu delegowanego, który określa uprawnienia dostępu. Na przykład firmy takie jak Amazon, Google, Facebook, Microsoft i Twitter umożliwiają użytkownikom udostępnianie informacji na ich kontach aplikacjom lub witrynom stron trzecich za pomocą mechanizmów udostępnianych przez OAuth.
Protokół OAuth 2 obejmuje następujące jednostki:
- Aplikacja kliencka: aplikacja internetowa lub mobilna, która wymaga dostępu do danych użytkownika w innej witrynie internetowej lub aplikacji.
- Właściciel zasobu (Resource Owner – RO): użytkownik, który jest właścicielem danych i upoważnia Aplikację Kliencką do uzyskiwania dostępu do danych.
- Serwer zasobów (Resource Server – RS): witryna lub aplikacja przechowująca dane należące do właściciela zasobu.
- Serwer autoryzacji (Authorization Server – AS): usługa tokenów zabezpieczających połączona z serwerem zasobów, która wydaje tokeny dostępu do danych przechowywanych na serwerze zasobów.
Zaprojektowany specjalnie do pracy z protokołem Hypertext Transfer Protocol (HTTP), protokół OAuth zasadniczo umożliwia wydawanie tokenów dostępu aplikacjom klienckim innych firm przez serwer autoryzacji za zgodą właściciela zasobu. Strona trzecia następnie używa tokena dostępu, aby uzyskać dostęp do danych, które są obsługiwane przez serwer zasobów.
Proces autoryzacji Open Authorization rozpoczyna się od określenia przez użytkownika końcowego (właściciela zasobu), że chce zapewnić aplikacji klienckiej dostęp do danych w aplikacji innej firmy (serwer zasobów). Aplikacja kliencka przekierowuje to żądanie do serwera autoryzacji połączonego z serwerem zasobów, który uwierzytelnia żądającego użytkownika końcowego (właściciela zasobów). Serwer autoryzacji następnie autoryzuje Aplikację Kliencką na dostęp do danych użytkownika na Serwerze Zasobów. Później przekierowuje użytkownika z powrotem do Aplikacji Klienckiej z jednorazowym kodem dostępu.
Jednorazowy kod dostępu jest wysyłany z powrotem do Serwera Autoryzacyjnego, gdzie jest konwertowany na token dostępu. Token ten Aplikacja Kliencka może użyć w celu uzyskania dostępu do Serwera Zasobów. Jednocześnie Serwer Autoryzacyjny może również odesłać refresh token, który pozwoli Aplikacji Klienckiej zażądać nowego tokena dostępowego w przypadku wygaśnięcia dotychczasowego.
Open Authorization to usługa uzupełniająca i odrębna od OpenID Connect (OIDC). OIDC i OAuth są często używane razem, przy czym OIDC zapewnia warstwę uwierzytelniania użytkownika, a OAuth jako warstwę autoryzacji/delegowanego dostępu.
Open Authorization jest protokołem autoryzacji, a nie protokołem uwierzytelniania, chociaż czasami jest używany jako metoda uwierzytelniania – czasami określany jako pseudo-uwierzytelnianie. Użytkownik (właściciel zasobu) jest zwykle uwierzytelniany w procesie przyznawania tokenu dostępu OAuth. Oznacza to, że OAuth jest czasami postrzegany jako metoda uwierzytelniania. Jednak OAuth nie został zaprojektowany z myślą o tym przypadku użycia i przyjęcie tego założenia może prowadzić do poważnych luk w zabezpieczeniach.
Protokół Open Authorization 1.0 został opublikowany jako RFC 5849 w kwietniu 2010 roku. Framework OAuth 2.0 został opublikowany jako RFC 6749 i 6750 w październiku 2012 roku.
Protokół Open Authorization 2.0 nie jest wstecznie zgodny z OAuth 1.0. OAuth 2.0 zapewnia określone przepływy autoryzacji dla aplikacji internetowych, aplikacji komputerowych, telefonów komórkowych i urządzeń inteligentnych.
Ponieważ Open Authorization 2.0 jest bardziej strukturą niż zdefiniowanym protokołem, jedna implementacja OAuth 2.0 niekoniecznie jest interoperacyjna z inną implementacją OAuth 2.0.
CO TO JEST Open Authorization 2.0?
Open Authorization 2.0 to struktura dostępu delegowanego, która została opublikowana jako RFC 6749 i 6750 w październiku 2012 r. OAuth 2.0 nie jest wstecznie zgodny z OAuth 1.0 i zapewnia określone przepływy autoryzacji dla aplikacji internetowych, aplikacji komputerowych, telefonów komórkowych i urządzeń inteligentnych.
JAKA JEST RÓŻNICA MIĘDZY OAUTH I SAML?
SAML (Security Assertion Markup Language) to oparty na języku XML standardowy format danych służący do wymiany danych uwierzytelniania i autoryzacji między dostawcą tożsamości a dostawcą usług. OAuth to otwarty standard, który umożliwia użytkownikom zapewnianie witrynom lub aplikacjom delegowanego dostępu do informacji przechowywanych w innych witrynach lub aplikacjach bez podawania danych uwierzytelniających aplikacji lub witryny w celu uzyskania bezpośredniego dostępu do konta (tj. hasła), na którym przechowywane są informacje.
Open Authorization może używać różnych formatów tokenów, w tym JSON Web Token (JWT) i formatu tokenu SAML.
CZY JWT TO OAUTH?
JSON Web Token (JWT) definiuje format tokena, a OAuth to protokół określający sposób uzyskiwania i przesyłania tokenów. OAuth może używać tokena JWT jako formatu tokena, ale może również używać innych formatów.
CZY OPENID TO TO SAMO CO OAUTH?
OAuth to usługa uzupełniająca i odrębna od OpenID Connect (OIDC). OIDC i OAuth są często używane razem z OIDC, zapewniając warstwę uwierzytelniania użytkownika i OAuth jako warstwę autoryzacji/delegowanego dostępu.
JAKIE SĄ RODZAJE DOSTĘPU?
Struktura autoryzacji OAuth 2.0 opisuje kilka metod, których aplikacja kliencka może użyć do uzyskania tokenu dostępu. Token ten może służyć do uwierzytelniania żądania w punkcie końcowym interfejsu API serwera zasobów. Różne metody nazywane są typami dostępu. Specyfikacja opisuje pięć dostępów (grantów) na uzyskanie tokena dostępu:
- Kod autoryzacyjny (Authorization Code): Przyznanie kodu autoryzacyjnego jest wysyłane do Aplikacji Klienta poprzez przekierowanie przeglądarki, a kod autoryzacyjny jest używany w tle w celu uzyskania tokena dostępu.
- Niejawny (Implicit): Niejawne przyznanie jest podobne do kodu autoryzacyjnego, ale zamiast używać kodu jako pośrednika, token dostępu jest wysyłany bezpośrednio przez przekierowanie przeglądarki.
- Poświadczenia właściciela zasobu (Resource Owner Credentials): Przyznanie hasła/poświadczeń właściciela zasobu wykorzystuje hasło właściciela zasobu w celu uzyskania tokenu dostępu. Hasło jest następnie odrzucane.
- Poświadczenia aplikacji klienckiej (Client Application Credentials): W trybie dostępu poświadczenia klienta, poświadczenia aplikacji klienta są używane zamiast poświadczeń właściciela zasobu.
- Refresh Token: Refresh Token służy do uzyskania nowego tokena dostępu po wygaśnięciu starego.
JAKIEGO TYPU TOKENY UŻYWA OAUTH?
Dwa typy tokenów zaangażowane w uwierzytelnianie Open Authorization 2 to token dostępu i refresh token.
- Access Token służy do autoryzacji żądania uzyskania dostępu do danych z serwera zasobów.
- Refresh Token jest normalnie wysyłany razem z tokenem dostępu i wykorzystywany, aby otrzymać nowy token dostępu po wygaśnięciu starego. Refresh Token służy jako rodzaj grantu aby otrzymać nowy token dostępu. Używanie refresh tokenów umożliwia wydawanie tokenów z krótkim czasem ważności przy zachowaniu dłuższego czasu wygaśnięcia ważności dostępu do serwera uwierzytelniającego.
CZY OAUTH JEST ROZWIĄZANIEM TOŻSAMOŚCI JAKO USŁUGI (IDAAS)?
Identity as a Service (IDaaS) to oparta na chmurze usługa zarządzania tożsamością i dostępem (IAM) obsługiwana przez dostawcę zewnętrznego. Korzystając z IDaaS, firmy subskrybujące mogą weryfikować poświadczenia użytkownika i zapewniać dostęp do zasobów i/lub ufających stronom, które mają relację zaufania z IDaaS. IDaaS jest szczególnie istotny dla przedsiębiorstw, które korzystają z usług w chmurze i nie zarządzają własną siecią ani nie hostują własnych serwerów i aplikacji.
Ponieważ użytkownik (właściciel zasobu) jest zwykle uwierzytelniany w procesie przyznawania tokenu dostępu OAuth, token OAuth jest czasami postrzegany jako metoda uwierzytelniania, a ponieważ jest to strona trzecia, która przeprowadza uwierzytelnianie, OAuth jest czasami mylony z IDaaS. To powiedziawszy, OAuth to nie jest IDaaS i nie powinien być używany do uwierzytelniania użytkowników.
