Endpointy do sign in i sign out w Spring Security

Endpointy do sign in i sign out w Spring Security
Sampeteq
SA
Sampeteq
SA
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 2 lata
  • Postów:94
0

Mam 2 endpointy, jeden /sgin-in do logowania i drugi /sign-out to wylogowywania. Zastanawiam się, jak to sensownie zaimplementować w Spring Security od strony serwisów. Wiadomo, muszę mieć jakiś AuthService z tymi metodami, ale co powinno się w nich znajdować? Nie pytam o oczywiste rzeczy takie jak sprawdzanie czy dane z dto zgadzają się z tymi z bazy tylko o to co potem. Wiem, że tworzy się UsernamePasswordAuthenticationToken, tylko gdzie go potem przekazać, żeby user został zalogowany a potem wylogowany?

Pseudo kod do momentu gdzie wiem co robić mniej więcej:

Kopiuj
void signIn(LoginDto dto) {
var user = getUserOrThrow(dto.username())
if (!user.password().equal(dto.password() ) ) {
throw new AuthException(dto.password())
}
new UsernamePasswordAuthenticationToken(dto.username(), dto.password())
...
//Nie wiem co dalej.
}


void signOut() {
//Skądś trzeba wziąć zalogowane usera, tylko skąd (SecurityContextHolder?) i co dalej?
}
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
LitwinWileński
LitwinWileński
LitwinWileński
LitwinWileński
  • Rejestracja:około 3 lata
  • Ostatnio:12 dni
  • Postów:740
0
SA
Widziałem to i nie do końca o to mi chodziło. Szukałem rozwiązania bez tych filtrów i innych cudów.
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
Sampeteq
SA
Sampeteq
SA
  • Rejestracja:ponad 3 lata
  • Ostatnio:ponad 2 lata
  • Postów:94
0

Znalazłem takie rozwiązanie na podstawie filmiku Hindusa na YT:

Kopiuj
package com.example.taskmanager.user;

import com.example.taskmanager.user.dto.SignInDTO;
import com.example.taskmanager.user.dto.UserDTO;
import com.example.taskmanager.user.exception.NotUniqueUserNameException;
import lombok.RequiredArgsConstructor;
import org.springframework.security.authentication.AuthenticationManager;
import org.springframework.security.authentication.UsernamePasswordAuthenticationToken;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.crypto.password.PasswordEncoder;

@RequiredArgsConstructor
class AuthService {

    private final PasswordEncoder passwordEncoder;
    private final UserRepository userRepository;

    private final AuthenticationManager authenticationManager;

    UserDTO signUp(String username, String password, UserRole role) {
        var correctUsername= Username.of(username);
        if (userRepository.existsByUsername(correctUsername)){
            throw new NotUniqueUserNameException(username);
        }
        var user = new User(
                correctUsername,
                Password.of(password).encoded(passwordEncoder),
                role,
                UserStatus.OPEN
        );
        return userRepository
                .save(user)
                .toDTO();
    }

    public void signIn(SignInDTO dto) {
        var token = new UsernamePasswordAuthenticationToken(dto.username(), dto.password());
        var correctToken= authenticationManager.authenticate(token);
        SecurityContextHolder.getContext().setAuthentication(correctToken);
    }

    public void signOut() {
        SecurityContextHolder.clearContext();
    }
}

Jest ok czy ktoś ma lepszy pomysł?

Charles_Ray
To jest jakieś dziwne. Nie dotykałem tego od paru lat, ale zwykle takie rzeczy ogarniały filtry, nie trzeba było używać SecurityContextHoldera. Nie jestem tez przekonany, że hasło powinno latać Stringiem. Poza tym naprawdę w 2022 trzeba z palca pisać rejestracje? :)
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj
piotrpo
piotrpo
piotrpo
piotrpo
  • Rejestracja:ponad 7 lat
  • Ostatnio:15 dni
  • Postów:3277
1

Jeżeli używasz JWT, to wylogowanie się zarządzane przez docelowy serwer staje się trochę mission impossible.
screenshot-20221004085414.jpg
Jak klient raz dostanie token, to ani AuthService, ani SecuredService nie mają nad nim kontroli.
Najprostszym sposobem wylogowania, jest "zapomnienie" tego tokena przez klienta. Jeżeli trzeba go unieważnić z poziomu zabezpieczanych usług, to nie ma możliwości zrobienia tego "prosto", bo jak widać SecuredService nie komunikuje się z AuthService w celu potwierdzenia ważności przesłanego tokena.
To co można zrobić, to:

  1. Nadawać krótki czas życia dla tokena i go odświeżać, wtedy np. po 5 minutach sam wygaśnie.
  2. Dodatkowo po stronie SecuredService można sobie zrobić (np. w pamięci) listę unieważnionych tokenów, i podczas sprawdzania weryfikować, czy dany token nie jest unieważniony.

Najprościej, tak jak pisałem, unieważnić token po stronie klienta, zwyczajnie wpisać token=null

Zobacz pozostałe 14 komentarzy
SO
No to czym to się różni od standardowej pary access i refresh token?
piotrpo
Zależy, w niektórych (coraz bardziej licznych) przypadkach niczym, bo access token z OAuth, może być w formacie JWT. Natomiast JWT nie musi być uzyskiwany OAuth (chociaż często jest), a OAuth nie musi zawsze wysyłać JWT.
SO
Na formacie token, tj. czy to JWT czy opaque bym się nie skupiał, bo to chyba tutaj nie ma znaczenia. Przejrzałem jeszcze raz ten RFC i to jest chyba generyczny endpoint do revoke tokenów, który może zrevokować albo access albo refresh token. Z tym, że dalej, jeśli użytkownik jest zalogowany na kilku urządzeniach i do przechowywania informacji o jego "sesji" używamy JWT to revoke nic nie da, bo albo revokujemy jeden access token (reszta dalej jest ważna) albo refresh token, czyli znowu tokeny przez X czasu są jeszcze ważne.
SO
Na początku myślałem, że @wartek01 to podlinkował jako mechanizm pozwalający definitywnie w danym momencie zrevokować wszystkie tokeny użytkownika. A znowu bez trzymania po stronie backendu wszystkich tokenów użytkownika ten mechanizm tego nie zapewni. A jak już chcemy trzymać wszystkie tokeny po stronie backendu to równie dobrze można użyć starej dobrej sesji po stronie backendu i ciasteczka sesyjnego na froncie :]
piotrpo
Dokładnie jak piszesz. Żeby odwołać jakikolwiek "selfcontaining token", trzeba mieć nad nim kontrolę, albo poinformować o fakcie jego odwołania wszystkich klientów. Jeżeli na wejściu do systemu mamy jakąś usługę, która łączy role API Gateway, z wystawcą refresh i access tokens, to teoretycznie może sobie trzymać w pamięci listę odwołanych i je na chama odrzucać. Tylko w takim przypadku cała idea istnienia takich tokenów bierze w łeb, bo po co się bawić, jak wystarczy sesja, gdzie nie ma problemu z jej unieważnieniem, albo wręcz basic auth.
Udostępnij
Kopiuj link do postu Kopiuj link do postu jako Markdown
Komentuj

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.

Utwórz konto