REST-API: Basic Authentication vs. OAuth 2.0

Podczas pracy z REST API można stosować różne mechanizmy uwierzytelniania w zależności od scenariusza i wymagań bezpieczeństwa. 

Pełny przegląd wszystkich mechanizmów znajduje się w naszym Przewodniku dla deweloperów: API Guide | BOC Developer Portal

Dwa często wymieniane metody to Basic Authentication oraz OAuth 2.0, ponieważ oferują one stosunkowo proste podejścia.

Chociaż obie metody umożliwiają dostęp do API, różnią się znacząco pod względem modelu bezpieczeństwa, nakładu konfiguracji oraz zamierzonych zastosowań. Wybór odpowiedniej metody to zatem nie tylko decyzja techniczna, ale także zależy od polityk bezpieczeństwa Twojej organizacji oraz rodzaju integracji, którą wdrażasz.
 

Ważne: 
Konfiguracja opisana w tym artykule musi zostać zweryfikowana pod kątem wewnętrznych polityk bezpieczeństwa i stanowi jedynie zalecenia najlepszych praktyk oraz wskazówki. 

Produkcyjne środowiska powinny być zawsze wdrażane i przeglądane przez doświadczonych administratorów IT.

Basic Authentication

Basic Authentication jest prostszym z dwóch podejść. Polega na przesyłaniu nazwy użytkownika i hasła z każdym żądaniem do API. Dzięki temu jest łatwa do skonfigurowania i nadaje się do szybkich testów lub prostych integracji.

Jednak ta prostota wiąże się z ograniczeniami. Ponieważ dane uwierzytelniające są przesyłane przy każdym żądaniu, nie ma rozdzielenia między uwierzytelnianiem a autoryzacją poza przypisanymi uprawnieniami użytkownika. Dodatkowo nie istnieje pojęcie czasu życia tokena ani dostępu ograniczonego zakresem, co obniża ogólny poziom bezpieczeństwa w porównaniu do OAuth.

Z tego powodu Basic Authentication jest zazwyczaj zalecana tylko dla nieprodukcyjnych scenariuszy lub krótkoterminowych testów.
 

Dokumentacja: Włączanie Podstawowej autoryzacji - BOC Docs

Wymagania dotyczące Podstawowej autoryzacji

Przy korzystaniu z Podstawowej autoryzacji muszą zostać spełnione następujące warunki użytkownika:

• Użytkownik musi być lokalnie zdefiniowany w systemie. 
• Nie można używać użytkowników importowanych ani uwierzytelnianych przez Single Sign-On (SSO). 
• Użytkownik nie może być skonfigurowany jako użytkownik techniczny.
• Skonfigurowany dostęp do Repozytorium.

Przy korzystaniu z Podstawowej autoryzacji muszą zostać spełnione następujące warunki systemowe:

Dostęp powinien być ograniczony na poziomie sieci poprzez zezwolenie tylko na określone adresy IP klientów: Uwierzytelnianie. 

Proszę zauważyć: Po konfiguracji należy przeprowadzić restart środowiska: Inicjatory restartu środowiska

OAuth 2.0

OAuth 2.0 zapewnia nowocześniejszy i bezpieczniejszy mechanizm uwierzytelniania i jest z tego powodu zalecanym podejściem dla środowisk produkcyjnych.

Zamiast przesyłać dane uwierzytelniające użytkownika, OAuth używa tokenów dostępu. Tokeny te mogą mieć ograniczony zakres i czas życia, co pozwala na znacznie lepszą kontrolę nad dostępem i zmniejsza ryzyko związane z ujawnieniem poświadczeń.

Dokumentacja: Włączanie OAuth 2.0 - BOC Docs
 

Przepływy OAuth 2.0

W zależności od scenariusza integracji stosuje się różne przepływy OAuth: 

Client Credentials Grant Type | BOC Developer Portal
Przepływ Client Credentials jest zwykle używany do komunikacji system-system. W tym przypadku nie jest wymagana interakcja użytkownika, a uwierzytelnianie odbywa się wyłącznie między komponentami technicznymi. Jest to najczęstsze podejście dla integracji backendowych i procesów automatycznych.
 

Authorization Code Grant Type | BOC Developer Portal
Przepływ Authorization Code jest wymagany, gdy potrzebny jest rzeczywisty kontekst użytkownika. Zazwyczaj ma to miejsce przy pracy z Single Sign-On (SSO), gdzie uwierzytelnianie jest delegowane do dostawcy tożsamości. Tylko ten przepływ umożliwia właściwe uwierzytelnianie oparte na użytkowniku w takich scenariuszach.

Wymagania dotyczące OAuth 2.0 Authorization Code Grant Type

Przy korzystaniu z OAuth 2.0 muszą zostać spełnione następujące warunki użytkownika:

• Podobnie jak w przypadku Podstawowej autoryzacji, użytkownik musi być lokalnie zdefiniowany i nie może być powiązany z SSO. 

• Ten użytkownik musi być wyraźnie skonfigurowany jako użytkownik techniczny w ustawieniach systemu.

• Musi być włączony „Zaufany login”.

• Skonfigurowany dostęp do Repozytorium.

Przy korzystaniu z OAuth 2.0 muszą zostać spełnione następujące warunki systemowe:

Druga część konfiguracji odbywa się za pomocą konektora, gdzie tworzony jest klient OAuth. Podczas tego procesu generowane są identyfikator klienta i sekret klienta, które są później używane do uzyskiwania tokenów dostępu: Uwierzytelnianie | ADONIS

Dostęp do API jest następnie kontrolowany przez zakresy (scopes), które dokładnie definiują, jakie operacje są dozwolone. Pozwala to na znacznie bardziej precyzyjny model autoryzacji w porównaniu do Podstawowej autoryzacji.

Proszę zauważyć: Po konfiguracji należy przeprowadzić restart środowiska: Inicjatory restartu środowiska
 

Rekomendacje

Dla środowisk produkcyjnych OAuth 2.0 powinno być zawsze preferowane ze względu na ulepszony model bezpieczeństwa i elastyczność.

Basic Authentication może być nadal użyteczna do szybkich testów lub początkowych konfiguracji, ale nie powinna być traktowana jako długoterminowe rozwiązanie w środowiskach o wyższych wymaganiach bezpieczeństwa.

Tworzenie oddzielnych klientów OAuth zapewnia wyraźny podział praw dostępu i upraszcza utrzymanie. Zmiany można wtedy wprowadzać w pojedynczej integracji bez wpływu na inne.