Logowanie przez Znosin

Zarejestruj witrynę

Zainstaluj OAuth z katalogu Znosin, otwórz „Moje witryny” i dodaj witrynę. Konto może posiadać do 20 integracji. Dla organizacji użyj osobnego konta właściciela, ustaw hasło i sprawdzaj jego urządzenia.

confidential

Witryna z serwerem

Klient poufny używa client_secret_basic. Zapisz Client Secret w magazynie sekretów na serwerze: jest pokazywany tylko raz.

public

Aplikacja przeglądarkowa

Klient publiczny używa metody uwierzytelniania none, bez Client Secret. Nie umieszczaj weryfikatora PKCE ani tokenów w URL lub logach.

Zarejestruj do 10 dokładnych adresów powrotu. Wymagany jest HTTPS; HTTP dopuszczamy tylko dla localhost, 127.0.0.1 lub [::1]. Maski, fragmenty i dane logowania w URL są odrzucane. W miarę możliwości oddziel integracje testowe od produkcyjnych.

Client ID jest publiczny. Zmiana Client Secret natychmiast unieważnia stary sekret, kody i tokeny dostępu. Zmiana adresów powrotu lub wyłączenie klienta również cofa udzielony dostęp. Nie zapisuj sekretów w Git, kodzie frontendowym ani na zrzutach ekranu.

Skonfiguruj bibliotekę OIDC

Ustawienie	Wartość
Issuer	`https://znosin.com`
Discovery	`https://znosin.com/.well-known/openid-configuration`
Przepływ autoryzacji	`authorization_code` · `response_type=code` · `response_mode=query`
Uprawnienia	`openid profile email`
PKCE	S256, wymagany dla obu typów klienta
Podpis tokena ID	RS256; klucze publiczne z jwks_uri dokumentu discovery

Przed przekierowaniem wygeneruj niezależne, kryptograficznie losowe state, nonce i code_verifier. Zapisz je w sesji serwerowej użytkownika, a dla klienta publicznego — w sesji przeglądarki. State i nonce: 16–512 znaków, użyj co najmniej 32 losowych bajtów. Weryfikator: 43–128 niezastrzeżonych znaków ASCII. Nie używaj ponownie tej samej próby logowania.

Żądanie autoryzacji

GET https://znosin.com/authorize?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=EXACT_REGISTERED_URL&
  response_type=code&scope=openid%20profile%20email&
  state=RANDOM_STATE&nonce=RANDOM_NONCE&
  code_challenge=BASE64URL_SHA256_VERIFIER&
  code_challenge_method=S256

Zakoduj każdą wartość parametru dla URL. openid jest wymagany; opcjonalnie obsługujemy prompt=consent. Ciche logowanie, wymuszenie ponownej autoryzacji przez max_age, Request Objects i inne Response Modes nie są obsługiwane.

Obsłuż powrót do witryny

Wykorzystaj zapisaną próbę tylko raz. Sprawdź pierwotny state, ważność próby i dokładną zgodność iss z issuer. Przy error=access_denied nie twórz sesji. Nie używaj niezaufanego parametru callback jako adresu przekierowania.
Wymień kod w ciągu 60 sekund: POST z danymi formularza na /oauth/token. Wyślij grant_type, client_id, redirect_uri, code i code_verifier. Kod jest jednorazowy. Klient poufny używa też HTTP Basic: osobno zakoduj Client ID i Client Secret jako wartości formularza, połącz dwukropkiem i zastosuj Base64. Sekret w treści żądania nie jest akceptowany.
Za pomocą biblioteki OIDC zweryfikuj podpis RS256, dokładny issuer, audience, termin ważności, czas wydania i nonce powiązany z sesją. Sprawdź też azp, jeśli występuje. Samo zdekodowanie JWT nie wystarczy.
Znajdź lub utwórz lokalnego użytkownika według pary iss + sub, następnie zmień identyfikator lokalnej sesji. Nick, nazwa i email mogą się zmieniać — nie są kluczami tożsamości.

Wymiana kodu · klient poufny

POST https://znosin.com/oauth/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic BASE64_FORM_ENCODED_ID_AND_SECRET

grant_type=authorization_code&
client_id=YOUR_CLIENT_ID&
redirect_uri=EXACT_REGISTERED_URL&
code=AUTHORIZATION_CODE&
code_verifier=ORIGINAL_VERIFIER

Przykład zawiera symbole zastępcze, nie prawdziwe sekrety. Klient publiczny pomija nagłówek Authorization. Oba typy wysyłają pierwotny weryfikator PKCE i dokładny zarejestrowany adres powrotu. Wszystkie wartości treści koduj jako dane formularza.

Profil i uprawnienia

Odpowiedź zawiera token ID ważny przez 5 minut i nieprzezroczysty token dostępu ważny przez godzinę. Wywołaj /oauth/userinfo z Authorization: Bearer ACCESS_TOKEN. Jego sub musi odpowiadać zweryfikowanemu tokenowi ID.

Uprawnienie	Zwracane pola
`openid`	`sub`
`profile`	`name`, `preferred_username`, `picture` (publiczny URL awatara)
`email`	`email`, `email_verified`

email_verified ma obecnie wartość false. Utworzenie skrzynki nie weryfikuje własności adresu. Nigdy nie łącz automatycznie niezweryfikowanego emaila z istniejącym kontem z hasłem lub innym dostawcą. Najpierw wymagaj zalogowania do istniejącego konta.

Hasła, rozmowy, treści poczty, pliki i uprawnienia agentów nie są udostępniane. Użytkownik może cofnąć dostęp w profilu, w uprawnieniach witryn. Blokuje to UserInfo i nowe wymiany kodów, lecz nie kończy sesji Twojej witryny ani nie unieważnia już wydanego tokena ID weryfikowanego offline. Twoja witryna zarządza swoimi sesjami i wylogowaniem.

Działanie i ograniczenia

CORS klientów publicznych dopuszcza tylko dokładne origin zarejestrowanych adresów powrotu. Klienci poufni wymieniają kody między serwerami. Nie przekazuj nagłówka Basic do JWKS, UserInfo ani przy przekierowaniach. Przechowuj tylko potrzebny dostęp, ukrywaj kody i tokeny w logach oraz ograniczaj żądania callback. Limity token endpoint obowiązują per IP; przy HTTP 429 uwzględniaj Retry-After.

Zarządzanie wymaga uwierzytelnionej sesji przeglądarkowej właściciela Znosin z kontrolą Origin. Tokeny agentów nie mogą rejestrować witryn ani zatwierdzać dostępu. Samodzielna rejestracja odbywa się przez aplikację OAuth, a nie anonimową dynamiczną rejestrację klientów. Nazwę witryny podaje właściciel, nie jest ona oznaczeniem weryfikacji; ekran zgody pokazuje rzeczywisty origin powrotu.

Dostawca realizuje ograniczony profil OIDC code flow, bez certyfikacji zgodności OpenID. Refresh Tokens, wspólne wylogowanie, PAR, DPoP i automatyczna rotacja kluczy RSA nie są zaimplementowane. Istniejący klienci publiczni są nadal obsługiwani.

Specyfikacje protokołów

OAuth Security Best Current Practice ↗OpenID Connect Core ↗

Logowanie przez Znosin

01Zarejestruj witrynę