Powiązane dokumenty
Protokół OAuth 2.0 jest ustandaryzowany zgodnie ze standardem RFC 6749. Szczegółowy dokument znajdziesz na https://oauth.net/2. Podstawowe uwierzytelnianie HTTP jest zdefiniowane w sekcji 2 standardu RFC 2617.
Przegląd
Aby zapewnić aplikacjom innych firm dostęp do ograniczonych zasobów, takich jak pakiet danych czy szczegóły portfela, użytkownik musi udostępnić zewnętrznemu swoje dane logowania. Powoduje to kilka problemów i ograniczeń, takich jak przechowywanie danych logowania, uwierzytelnianie haseł, szeroki dostęp do zasobów użytkownika i wyciek hasła. Rozwiązanie tego problemu dotyczy protokołu OAuth2.0 przez wprowadzenie warstwy autoryzacji i zabezpieczanie dostępu do chronionych zasobów użytkownika.
Zamiast korzystania z danych logowania użytkownika końcowego, aby uzyskać dostęp do chronionych zasobów, takich jak szczegóły abonamentu, GTAF uzyskuje token dostępu. Tokeny dostępu są przyznawane GTAF w imieniu danych logowania GTAF. GTAF wykorzystuje token dostępu, aby uzyskać dostęp do szczegółowych informacji o planie danych przechowywanych przez organ ochrony danych.
Poniższa ilustracja przedstawia ogólny przepływ informacji:
Rysunek 1. Abstrakcyjny schemat OAuth.
Tokeny dostępu
Tokeny dostępu to dane logowania, których GTAF używa do uzyskania dostępu do szczegółowych danych pakietu danych u operatora. Token dostępu to ciąg znaków reprezentujący autoryzację autoryzowaną do GTAF. Ciąg jest zazwyczaj nieprzezroczysty dla GTAF. Tokeny reprezentują określone zakresy i czasy dostępu przyznane przez użytkownika operatorowi oraz są egzekwowane przez serwer DPA i serwer OAuth operatora.
Token dostępu zapewnia warstwę abstrakcji, zastępującą różne konstrukcje autoryzacji (np. nazwę użytkownika i hasło) pojedynczym tokenem zrozumiałym dla organu ochrony danych. Ta abstrakcja umożliwia bardziej restrykcyjny dostęp do tokenów dostępu niż przyznawany, aby je uzyskać, a także usunięcie Aneksu o przetwarzaniu danych. Konieczne jest zrozumienie różnorodnych metod uwierzytelniania.
Tokeny dostępu mogą mieć różne formaty, struktury i metody wykorzystania (np. właściwości kryptograficzne) w zależności od wymagań bezpieczeństwa operatora. GTAF obsługuje tylko tokeny dostępu typu okaziciela zdefiniowane w [RFC6750].
Uwierzytelnianie klienta
GTAF działa jako „poufny klient” i może dbać o bezpieczeństwo haseł. GTAF obsługuje obecnie tylko uwierzytelnianie podstawowe HTTP, które pozwala uwierzytelnić za pomocą Aneksu o przetwarzaniu danych. Identyfikator klienta jest kodowany przy użyciu algorytmu &"application/x-www-form-urlencoded", a zakodowana wartość jest używana jako nazwa użytkownika; hasło jest kodowane za pomocą tego samego algorytmu i używane jako hasło.
Klienty poufne, takie jak GTAF, które wysyłają dane logowania klienta, uwierzytelniają się na serwerze OAuth operatora podczas wysyłania żądań do punktu końcowego tokena. Uwierzytelnianie klienta jest używane w przypadku: \
- Odzyskiwanie zhakowanego klienta przez jego wyłączenie lub zmianę danych logowania w taki sposób, aby uniemożliwić atakującemu nadużywanie tokenów odświeżania. Zmiana pojedynczego zestawu danych logowania klienta jest znacznie szybsza niż unieważnienie całego zestawu tokenów odświeżania.
- Wdrażam sprawdzone metody zarządzania uwierzytelnianiem, które wymagają okresowej rotacji danych logowania.
GTAF używa parametru "client_id" żądania do identyfikowania się podczas wysyłania żądań do punktu końcowego tokena.
W szczególności chodzi o możliwość rotacji danych logowania klientów. Serwer OAuth musi obsługiwać dwie równoczesne pary danych logowania podczas rotacji i mieć możliwość wyłączenia danych logowania. W typowej rotacji danych logowania:
- Operator tworzy nowe dane logowania na serwerze OAuth i w bezpieczny sposób przekazuje dane logowania do technicznego menedżera konta.
- Google testuje nowe dane logowania i zmienia konfigurację GTAF, aby je używać.
- Google powiadomi operatora, że stare dane logowania mogą zostać wyłączone.
- Operator wyłącza dane logowania i powiadomia Google
- Google sprawdza, czy stare dane logowania nie działają
Serwer OAuth musi obsługiwać powyższy proces rotacji.
Punkt końcowy tokena
Punkt końcowy tokena jest używany przez GTAF do uzyskania tokena dostępu przez prezentację jego przyznania autoryzacji lub odświeżenia. Punkt końcowy tokena jest używany ze wszystkimi uprawnieniami do autoryzacji z wyjątkiem typu uwierzytelnienia domyślnego (ponieważ token dostępu jest wystawiany bezpośrednio).
Podczas konfigurowania punktu końcowego tokena weź pod uwagę te kwestie:
- Lokalizacja punktu końcowego tokena powinna być podana w dokumentacji usługi.
- Identyfikator URI punktu końcowego może zawierać sformatowany komponent „"application/x-www-form-urlencoded"”, który trzeba zachować podczas dodawania dodatkowych parametrów zapytania. Identyfikator URI punktu końcowego nie może zawierać komponentu fragmentu.
- Ponieważ żądania wysyłane do punktu końcowego tokena powodują przesyłanie danych uwierzytelniających tekstu tekstowego (w żądaniu i odpowiedzi HTTP), serwer OAuth operatora musi używać TLS do wysyłania żądań do punktu końcowego tokena.
- Podczas wysyłania żądania tokena dostępu GTAF korzysta z metody HTTP "POST".
- Parametry wysłane bez wartości muszą być traktowane jako pominięte w żądaniu. Serwer OAuth musi zignorować nierozpoznane parametry żądania. Parametry żądania i odpowiedzi nie mogą być dodane więcej niż raz.
- GTAF obsługuje tylko tokeny dostępu typu okaziciela.
Zakres tokena dostępu
Punkty końcowe autoryzacji i tokenów pozwalają klientowi określić zakres żądania dostępu za pomocą parametru "scope". Serwer autoryzacji używa natomiast parametru "scope" do informowania klienta o zakresie wystawionego tokena dostępu.
Wartość parametru zakresu jest wyrażona jako lista ciągów rozdzielanych spacjami (wielkość liter ma znaczenie). Ciągi są zdefiniowane przez serwer autoryzacji. Jeśli wartość zawiera kilka ciągów rozdzielonych spacjami, ich kolejność nie ma znaczenia, a każdy ciąg dodaje dodatkowy zakres dostępu do żądanego zakresu.
scope = scope-token *( SP scope-token )
scope-token = 1*( %x21 / %x23-5B / %x5D-7E )
GTAF nie wymaga wdrożenia zakresu, ale obsługuje tę funkcję. Więcej informacji znajdziesz w sekcji 3.3 dokumentu RFC 6749.
Wydanie tokena dostępu
Jeśli żądanie tokena dostępu wysłane przez GTAF jest prawidłowe i autoryzowane, serwer OAuth wystawia token dostępu i opcjonalny token odświeżania. Jeśli żądanie nie przejdzie do uwierzytelniania klienta lub będzie ono nieprawidłowe, serwer OAuth zwróci odpowiedź w sposób opisany poniżej.
Wykonana odpowiedź
Gdy GTAF wysyła żądanie, serwer OAuth wysyła token dostępu i opcjonalny token odświeżania, a następnie tworzy odpowiedź, dodając do parametru encji w odpowiedzi HTTP kod stanu 200 (OK):
- access_token: WYMAGANY. Token dostępu wydany przez serwer OAuth. GTAF oczekuje, że punkt końcowy tokena zwróci token okaziciela.
- expires_in: WYMAGANE. Czas życia tokena dostępu w sekundach. Na przykład wartość "3600" oznacza, że token dostępu wygaśnie po godzinie od wygenerowania odpowiedzi. W przypadku pominięcia wartość serwer OAuth powinien podawać czas wygaśnięcia w inny sposób lub udokumentować wartość domyślną.
- token_type: WYMAGANY. Typ wystawionego tokena. Więcej informacji na temat różnych typów tokenów znajdziesz w sekcji 7.1 RFC 6749. Wielkość liter w wartości nie jest rozróżniana. GTAF obsługuje obecnie tylko tokeny okaziciela.
- Refresh_token: OPTIONAL. Token odświeżania, który można wykorzystać do uzyskania nowych tokenów dostępu przy użyciu tego samego przyznania autoryzacji.
- zakres: OPCJONALNY, jeśli jest zaimplementowany i identyczny z zakresem wymaganym przez GTAF. W przeciwnym razie jest wymagany.
Parametry są umieszczane w treści encji w odpowiedzi HTTP za pomocą ciągu &&tt;application/json". Parametry są serializowane w strukturze JSON (JavaScript Object Notation), dodając każdy parametr na najwyższym poziomie struktury. Nazwy parametrów i ich wartości są podawane w postaci ciągów JSON. Wartości liczbowe są podawane w formacie JSON. Kolejność parametrów nie ma znaczenia i może się różnić.
Serwer autoryzacji MUSI zawierać pole nagłówka HTTP "Cache-Control" z wartością "no-store" w każdej odpowiedzi zawierającej tokeny, dane logowania lub inne informacje poufne, a także pole "Pragma" odpowiedzi z wartością "no-cache".
Przykład:
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"Bearer",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
Kilka ważnych kwestii:
- GTAF ignoruje w odpowiedzi nierozpoznane nazwy wartości.
- Rozmiary tokenów i inne wartości odebrane z serwera OAuth są nieokreślone.
- Ustawa GTAF nie powinna zakładać wartości rozmiarów. Serwer OAuth powinien udokumentować rozmiar dowolnej wartości.
Odpowiedź błędu
Jeśli żądanie autoryzacji nie powiedzie się z jakiegoś powodu, np. z powodu brakującego, nieprawidłowego lub niezgodnego identyfikatora URI przekierowania albo z brakiem identyfikatora klienta lub jest on nieprawidłowy, serwer OAuth powinien podać kod stanu HTTP 400 (nieprawidłowe żądanie) i powinny zawierać co najmniej 1 z parametrów wymienionych w sekcji Odpowiedź błędu i Kody.
Przyznanie autoryzacji w GTAF
Przyznanie autoryzacji to dane logowania, które reprezentują autoryzację użytkownika (dostęp do chronionych zasobów, takich jak informacje o saldzie danych) używane przez GTAF do uzyskania tokena dostępu.
GTAF korzysta z typu uwierzytelnienia client_credentials. W typie uwierzytelnienia client_credentials GTAF żąda tokena za pomocą żądania POST w protokole HTTP i uwierzytelniania podstawowego HTTP. Wszystkie żądania są wysyłane przez protokół TLS (tj. HTTPS) i GTAF nie może zostać zintegrowany z serwerem OAuth bez ważnego certyfikatu TLS. GTAF może przekazywać konfigurowany zakres tokenów, a jeśli nie jest skonfigurowany, przekazuje pusty zakres.
GTAF oczekuje, że token dostępu zostanie zwrócony wraz z wartością "expires_in" (czas życia). Wartość parametru valid_in powinna wynosić co najmniej 900 sekund i nie powinna przekraczać kilku godzin. Zgłaszanie prośby o nowy token nie może powodować wygaśnięcia wcześniejszych tokenów.
Więcej informacji na temat różnych typów uwierzytelniania znajdziesz w sekcji 1.3 RFC 6749.
Przykładowe żądanie i odpowiedź
Załóżmy, że plik GTAF ma taką konfigurację serwera OAuth:
URL: https://www.example.com/gettoken/
Client ID: gtaf
Client secret: password
Scope: dpa
Uwaga: tajny klucz klienta rzeczywistej ochrony danych musi być znacznie bezpieczniejszy niż ten widoczny w przykładzie.
Aby wygenerować ciąg autoryzacji, identyfikator klienta &&33;:' oraz hasło są ze sobą połączone i zakodowane w formacie base64. Możesz to odtworzyć w interfejsie wiersza poleceń w ten sposób:
$ echo -n gtaf:password | base64
Z3RhZjpwYXNzd29yZA==
GTAF wysyła żądanie HTTPS POST do serwera OAuth, korzystając z tych danych logowania, typu uwierzytelnienia client_credential i skonfigurowanego zakresu. W tym przykładzie żądanie GTAF' wygląda podobnie do tego, które zostało wygenerowane przez:
$ curl -H 'Authorization: Basic Z3RhZjpwYXNzd29yZA==' -X POST \
-d 'grant_type=client_credentials&scope=dpa' 'https://www.example.com/gettoken/'
Nagłówki używane przez GTAF nie będą zgodne z nagłówkami wysyłanymi przez curl, ale nagłówek autoryzacji będzie identyczny.
GTAF oczekuje odpowiedzi w formularzu:
{
"access_token":"<token>",
"token_type": "Bearer",
"expires_in":<expiration time>
}
Poniżej znajduje się przykład prawidłowej odpowiedzi:
{
"access_token":"YXRudWhhZXVoLGFodWFoaGF1aG9zaHVvYWV1Cg",
"token_type": "Bearer",
"expires_in":3600
}
Uwaga: odpowiedź musi być prawidłowym plikiem JSON.
Odpowiedź i kody błędów
Jeśli żądanie autoryzacji z GTAF nie powiedzie się z dowolnego z powodów wymienionych w sekcji Odpowiedź błędu, serwer OAuth musi udzielić kodu stanu HTTP 400 (nieprawidłowe żądanie) i w odpowiedzi podać jeden z tych parametrów:
Na przykład: \
HTTP/1.1 400 Bad Request
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
"error":"invalid_request"
}
GTAF oczekuje, że serwer OAuth będzie obsługiwać te odpowiedzi dotyczące błędów:
| Kod błędu | Odpowiedź | Uzasadnienie |
| HTTP 400 | Invalid_request (nieprawidłowe żądanie) | Żądanie nie zawiera wymaganego parametru, zawiera nieobsługiwaną wartość parametru (inną niż typ uwierzytelnienia), powtarza parametr, używa wielu danych logowania, używa więcej niż jednego mechanizmu uwierzytelniania w GTAF lub jest w inny sposób zniekształcony. |
| HTTP 401 | Invalid_client (nieprawidłowy_klient) | Uwierzytelnianie klienta nie powiodło się (np. nieznany klient, brak uwierzytelniania klienta lub nieobsługiwana metoda uwierzytelniania). Serwer OAuth może zwrócić kod stanu HTTP 401 (Brak autoryzacji), by wskazać, które schematy uwierzytelniania HTTP są obsługiwane. Jeśli klient próbował uwierzytelnić się za pomocą pola nagłówka „"Authorization" request”, serwer OAuth musi udzielić kodu stanu HTTP 401 (Brak autoryzacji) i dodać pole „"WWW-Authenticate"” zgodne ze schematem uwierzytelniania używanym przez klienta. |
| HTTP 500 | Błąd serwera OAuth |
Szczegółowe informacje o innych odpowiedziach, które można wykorzystać do debugowania, znajdziesz wsekcji 5.2 artykułu RFC 6749.