스프링 시큐리티 jwt 와 sso 그리고 로그인

Question

요즘 하는 프로젝트가 백단에 스프링 시큐리티로jwt 토큰을 만들고 그걸로 로그인을 하고sso도 한다고 하는데실제 코드도 구현되어 있고프론트에서 param으로 jwt 토큰을 싣어서백단으로 보내기도 하는데요근데 이게 한 사이클로 연결이 되어서이해는 아직 못하겠습니다.사실 jwt 토큰의 정체도 아리까리 하고이게 로그인과 sso랑 어떻게 연결이 되는건지그리고 콘솔 로그에 헤더에 jwt 토큰이 없다는 메시지도 뜨는데 지금 당장 로그인은 잘 되거든요이 콘솔 메시지는 무슨 상태인건지도 명확히 모르겠습니다.개념을 설명해 주세요 ㅠㅜ

Super Novice · Answer

개념은 검색하거나 gpt 한테 물어보시면 잘나와요 하나하나씩 개념부터 알아내시고 검색하다 모르는게 있으면 그게 뭔지 또 검색하고 그러다보면 알게되실것같습니다.

오후 · Answer

일단 jwt 와 sso 는 분리해서 생각하셔야될거같고SSO 는 말그대로 여러 어플리케이션(홈페이지)에서 인증(로그인)을 통합 관리한다고 생각하시면됩니다.(패밀리사)세션방식이 서버가 인증(로그인)정보를 관리하는 개념이라면 JWT 는 관리를 프론트(유저)가 관리한다고 생각하시면됩니다.콘솔 로그에 뜨는 부분은 아마도 지금 적어주신 내용상 토큰을 param 으로만 보내서 header 에 없다고 뜨는거 같네요.Header : Authorization: ex) Authorization Bearer(or JWT등 내부 규칙에따라) JWT_Header.JWT_Payload.JWT_Signature

집킨 · Answer

몇년차시길래 jwt를 아리까리라고 하시는지..?(주니어면 그럴 수 있습니다만)jwt를 확실하게 알고 싶으면, "세션을 이용한 인증" 방식을 검색해보세요그리고 세션 방식의 단점과 한계를 검색해보세요그리고 jwt를 검색해서 보세요jwt가 세션 방식의 단점과 한계를 어떻게 해결해줄 수 있는지도 생각해보면 됩니다이 관점으로 봐야 jwt가 와닿을거에요

돌아온크리미드림 · Answer

개념은 이것

RWB · Answer

다른분들 말씀처럼 일단 SSO와 JWT의 기본적인 개념에 대해 알아보시는 걸 추천드립니다.또한 SSO와 JWT의 개념은 별개로 구분하셔야 합니다물론 JWT가 인증의 보편적 요소는 맞으나, JWT는 SSO의 필수 구성요소가 아닙니다.SSOSSO는 통합 로그인을 의미합니다. 여기서의 통합이란, 별개로 관리되는 여러 서비스의 인증을 통합함을 의미합니다.카카오 로그인을 생각해보세요. 카카오 서비스의 계정 하나로 카카오톡, 카카오T, 카카오뱅크 등 여러 서비스를 활용할 수 있습니다.일반적인 서비스와 달리, 이런 SSO 형태는 서비스가 인증 모듈을 포함하지 않습니다. 서비스 입장에서 인증 모듈 또한 하나의 외부서비스처럼 대하게 됩니다 (API, SDK 등)따라서 대부분의 SSO는 인증 서비스라는 별도의 서비스로 인증을 관리하게 됩니다.즉, 카카오톡, 카카오T와 같이 카카오 인증이라는 일종의 인프라 모듈이 있는 셈이며, 모든 서비스는 카카오 인증이라는 "외부 모듈"을 참조하는 형태로 구성됩니다.이런 구조는 각 서비스의 기술적, 구조적 독립성을 유지하면서도 인증 체계를 통합할 수 있습니다.이 SSO 인증모듈을 OAuth 프로토콜에 입각하여 구현하면, OAuth 인증 또한 제공할 수 있습니다.JWT내부 인증 모듈이든, SSO 같은 외부형 인증 모듈이든 인증을 판단하는 요소가 반드시 필요합니다.이 때 보편적으로 사용하는 요소가 JWT입니다.JWT는 일정한 규칙으로 암호화된 문자열이며, 이 토큰은 헤더, 페이로드(내용), 시그니쳐로 구성되어 있습니다.일반적인 암호문과 다르게, JWT의 내용을 확인하는 건 매우 쉽습니다. 아무 JWT 가져가다 복호화 시키면 내요을 볼 수 있습니다.하지만 JWT 라이브러리에선 매칭되는 시그니쳐가 아니면 실제 페이로드를 파싱하지 않고 오류를 Throw합니다.하지만 수동으로 내용을 볼 순 있기에, JWT에 중요한 내용을 넣어선 안 됩니다.세션의 경우 외부 형태의 인증 서비스에 적합하지 않습니다. 세션의 사용량은 서버의 부하로 직결되므로, 인증된 사용자가 많아질수록 서버의 부하도 증가하게 됩니다.특히 외부형 인증모듈은 이런 형태로 각 사용자의 상태를 알 필요가 없습니다. 세션은 이러한 Stateless에 적합하지 않기에, 많이 사용되지 않습니다.때문에 Stateless 서비스를 구현하기 위한 차선책 중 하나로 토큰을 생각해볼 수 있습니다.토큰의 가장 큰 특징은 HTTPS 전용과 HttpOnly 옵션입니다. 특히 HttpOnly는 JS가 쿠키를 건들지 못하게 하여, 스크립트에서의 탈취를 방지하는 보안적 이점도 있습니다.이런 쿠키는 Set-Cookie라는 헤더를 통해 지시하는데, 이 헤더는 기본적으로 같은 도메인 내에서만 동작하기 때문에, 인증을 제공할 서비스가 많아질수록 관리 포인트가 늘어난다는 단점이 있습니다.JWT가 나오게 되면서 Stateless 특징, 범용적인 활용, 규격화된 구조의 특징을 발판삼아 여러 곳. 특히 인증의 수단으로 채택하고 있습니다.로그인 시 Param을 통해 서비스에게 JWT 토큰을 제공하고, 서비스는 인메모리 혹은 DB, 브라우저 객체에 저장하여 인증 요구 시 활용합니다.이 때 JWT는 params보단 Authorization같은 헤더를 주로 사용합니다.

catcode · Answer

JWT는 각 토큰별 저장위치나 갱신주기를 커스텀해서 관리합니다저는 액서스토큰은 쿠키에, 리프레쉬 토큰은 RDB에 저장하는걸 선호합니다.액서스 토큰: 이게 있으면 별도의 인증없이 통과 (갱신주기 짧음)리프래쉬 토큰: 이걸로 액서스 토큰 생성 (갱신주기 긺)SSOA서비스에서 로그인되어있는 유저가 B서비스로 옮겨갈때 자동로그인

dw kim · Answer

Sso는 인증방식 중 하나로 러프한 용어이고Jwt는 토큰인증 방식의 한 방법입니다

코가더 · Answer

한개씩 풀어서 조지워싱턴 하세요 ㅋ

yeori · Answer

jwt 토큰을 서버에 보내는 방식이 크게 두 가지입니다.1. 쿠키에 말아넣기이거는 사용자가 로그인을 하면 대응하는 jwt 토큰을 __서버에서__ 생성한 후에 http 응답을 보낼 때 쿠키에 써줍니다.@RestController public class AuthController { @GetMapping("/login") public String login(HttpServletResponse response) { // 예시: 로그인 성공했다고 가정 String username = "testUser"; // JWT 토큰 발급 String jwtToken = JwtUtil.generateToken(username); // 쿠키 생성 Cookie cookie = new Cookie("jwt", jwtToken); cookie.setHttpOnly(true); // XSS 방지 (JS 접근 불가) cookie.setSecure(true); // HTTPS 환경에서만 전송 (개발 시에는 false 가능) cookie.setPath("/"); // 모든 경로에서 접근 가능 cookie.setMaxAge(60 * 60); // 쿠키 유효시간: 1시간 // 응답 헤더에 쿠키 추가 response.addCookie(cookie); return "JWT 토큰이 쿠키에 저장되었습니다."; } }사용자의 브라우저에서는 이 쿠키값을 갖고 있다가 서버로 요청이 날아갈 때 자동으로 같이 첨부됩니다.(따로 프론트엔드에서 처리할 게 없다는 점이 장점입니다.)이후 http 요청이 들어오면 서버는 http 요청의 쿠키 인에 jwt 토큰이 있는지 찾습니다.2. http 헤더에 말아넣기1번과 다른 점은 쿠키가 아니라 요청, 응답 헤더에 써넣는다는 것,그리고 쿠키 방식과 다르게 프론트엔드에서 요청을 보낼 때 헤더에 jwt 톸큰값을 써줘야 합니다.로그인 후 서버가 헤더에 jwt 토큰을 실어서 보내줄텐데(아래와 같이) @GetMapping("/login-header") public String login(HttpServletResponse response) { String username = "testUser"; // JWT 발급 String jwtToken = JwtUtil.generateToken(username); // Authorization 헤더에 담기 ("Bearer " + 토큰 형식이 일반적) response.setHeader("Authorization", "Bearer " + jwtToken); }이런 경우 프론트엔드에서는 http 응답의 헤더(Authorization)를 까서 jwt 토큰을 어딘가에 저장해 둬야 합니다.그리고 브라우저에서 서버로 요청을 보낼 때 이 jwt 토큰을 다시 헤더에 써줘야 합니다.let jwt = loadJwtTokenSomewhere(); fetch("/api/protected", { method: "GET", headers: { "Authorization": "Bearer " + jwt } }) .then(res => res.json()) .then(data => console.log(data));fetch API든 axios든 jquery든 동일함.쿠키는 브라우저가 자동으로 전송하고 다시 전송받아서 관리하니까 위와 같은 작업이 필요없지만,헤더에 실어보내고 받을때는 위의 로직을 매번 실행해 줘야 합니다.보통은 hook 구현체로 감싸서 등록하고 매번 자동으로 실행되게 함..근데 단순 링크의 경우는 위 기능이 실행되지 않습니다.내 정보저거 클릭하면 http 요청이 쌩으로 날아가기 때문에 헤더에 jwt 토큰이 없고, 인증 정보가 필요한 요청이면 서버쪽에서 토큰이 없어서 삑사리 납니다.어찌어찌 자바스크립트로 처리할 수는 있습니다. 좀 더러움...정리하면 전통적인 웹애플리케이션이라면 쿠키 방식이 상대적으로 편하고,SPA로 작성된 웹애플리케이션에서는 헤더 방식이 더 유연합니다.(근데 어거지로 막 어찌어찌 하려고 하면 되기는 합니다.)3. param에 말아넣기이거는 개인적으로 본 적이 없습니다.굳이 추측하자면 헤더나 쿠키에 jwt 말어넣으면 이거 꺼내는 코드가 필요하고 또 매번 실행해야 합니다.이게 귀찮아서 @RequstParam으로 받아쓰려는 의도가 아닌가 싶고,그래서 jwt 토큰을 찾아내서 메소드 인자에 꽂아주는 AOP 구현체를 달아줌. 이거 매번 controller에서 실행하는 것도 못 할 짓입니다.어쩌면 쿠키나 헤더에 토큰을 쓰고 읽는 구현을 붙이기 힘들거나, 또는 잘 몰라서 궁여지책으로 param을 이용한 게 아닌가 싶기도 하고...그 코드의 맥락을 모르니까 평가하기는 애매한데, 개인적으로는 못 봤습니다.

MuDaeng · Answer

콘솔메시지는 사진이 삭제됐나용옛날인터넷에는 쿠키밖에 없어서 쿠키만 썼는데로컬스토리지 생기고나서 로컬스토리지 쓰는 추세입니다.헤더에 Authorization 쓰면 포스트맨이나 스웨거로 테스트하기 편하기도 하쥬콘솔로그에 헤더에 토큰 없다는건 param으로 넣어서 헤더에ㅜ없다는고 아니에여?

Nh드림 · Answer

영한이형 인트런 강의보면 이해하기 편할거에유댓글읽다보니 오후님이 기본 개념은 설명을 잘해주셨네요header에 bearer ~~~~~~ 요런식으로 넣슴다

스프링 시큐리티 jwt 와 sso 그리고 로그인

11개의 답변

#sso 목록