안녕하세요.질문 먼저 요약하자면,id token 에 scope에 포함된 유저 정보가 같이 포함되어 넘어오는게 일반적인지, idtoken 검증만 진행한 뒤 액세스토큰으로 따로 조회하는게 일반적인지 궁금합니다. 1년쯤 전에, 소셜 로그인의 흐름을 이해해보기 위해 스프링 시큐리티 없이 카카오, 네이버, 구글 로그인을 적용해본 적이 있습니다.원래 카카오와 구글은 OIDC를 지원했고, 네이버는 OIDC가 없었는데 최근에 추가되었더라구요.그래서 OAuth2 스펙으로만 구성된 네이버 로그인 코드를 OIDC를 적용한 코드로 수정하고 있었는데.. 그러다가 의문이 생겨서 질문을 드리게 되었습니다. 저는 여태까지 필요한 유저 정보의 scope를 "openid" 항목과 함께 프로바이더에 전달하고,id token을 프로바이더로부터 전달받고, 그걸 검증한 뒤 id token에 담긴 유저 정보를 사용하면 된다고 생각하고 있었습니다.실제로 카카오와 구글은 유저의 email 정보가 id token 페이로드에 담겨있었구요. 네이버 역시 https://nid.naver.com/.well-known/openid-configuration 의 메타데이터 중 scopes_supported 항목을 확인했을때 profile이라는 scope가 존재해서, 코드 요청할때 scope=openid+profile 을 파라미터로 전달했습니다.그런데 id token을 확인해도 유저의 정보가 나오지 않더군요. 처음에는 단순히 네이버가 이 부분을 미구현했나? 생각을 했는데, 좀 찾아보니 id token에는 최소한의 신원만을 포함하고 세부적인 프로필은 따로 조회하는게 맞다는 말도 있더라구요. 그래서 질문을 올리게 되었습니다.

폼로그인 방식에서 시큐리티가 제공하는 기본 로그인 페이지를 사용하지 않으려고 해당 설정을 하는것으로 아는데요그런데 IndexController는 RestControlle인데, html뷰는 어떻게 사용자에게 보여주나요? 기본적으로 RestController는 http 리턴으로 알 고 있습니다.

@EnableWebSecurity 꼭 붙여야 된다고 하셨는데 안붙여도 움직이는데 붙이고 안붙이고의 차이가 있나요?의존성에 spring-security 들어가 있으면 AutoConfiguration 에 의해 자동구성된다면 붙일 이유가 없을것 같은데 뭔가 다른게 더 초기화작업에 추가되거나 하는건가요?

안녕하십니까 선생님, 이렇게 세션을 Redis에 저장할 때에는 예외 발생 시 트랜잭션, 롤백 같은 기능은 어떤 식으로 처리를 해야 하는 지 질문 드립니다.

68. 인증 이벤트 - AuthenticationEventPublisher 활용 강좌 중간중간에 음성이 나오지 않아 글 작성 합니다.

안녕하십니까 선생님, 양질의 강의 항상 감사드립니다.AuthenticationManager와 AuthenticationProvider의 구성에 대해서 개념적으로 확인하고 싶은 것이 있어 질문 드립니다.AuthenticationProvider를 직접 구성하여 등록하지 않으면 기본적으로 DaoAuthenticationProvider, BasicAuthenticationProvider, RememberMeAuthenticationProvider 가 등록이 되는데, 직접 커스텀한 Provider를 등록 시 이 3개의 기본 Provider들은 자동 구성에서 제외 되는 것 인가요?만약 AuthenticationManger를 builder 혹은 직접생성(new)을 통해 생성한다면 기본 제공 되는 Provider들은 자동 구성에서 제외되는 것 인가요? 만약 그렇다면 AuthenticationManager는 직접 등록하고 싶은 Provider가 있을 때에만 생성하는 것 인가요?

현재 제 build.gradle은plugins { id 'java' id 'org.springframework.boot' version '3.5.0' id 'io.spring.dependency-management' version '1.1.7' } group = 'io.security' version = '0.0.1-SNAPSHOT' java { toolchain { languageVersion = JavaLanguageVersion.of(17) } } repositories { mavenCentral() } dependencies { implementation 'org.springframework.boot:spring-boot-starter-security' implementation 'org.springframework.boot:spring-boot-starter-web' testImplementation 'org.springframework.boot:spring-boot-starter-test' testImplementation 'org.springframework.security:spring-security-test' testRuntimeOnly 'org.junit.platform:junit-platform-launcher' } tasks.named('test') { useJUnitPlatform() } 같이 설정이 되어 있습니다. AntPathRequestMatcher, MvcRequestMatcher가 사용이 되지 않는다고 자동완성때 밑줄이 쳐져 있어서.requestMatchers("/manager/**").hasAuthority("ROLE_MANAGER") .requestMatchers("/admin/payment").hasAuthority("ROLE_ADMIN")이렇게 수정하였는데 맞게 수정 한 것인지 문의 드립니다.

저는 그래도 최신버전으로 테스트 하면서 비교를 해가며 학습하는게 좋겠다 싶어 학습중입니다.현재 springboot 3.5으로 학습중이며 security는 6.3인것 같습니다.그런데 학습 중 바뀐부분이 있는것 같아 확인 부탁 드리고 자 글을 남깁니다. 아래 내용이 맞는지 알고 싶어요..ㅠㅠ 🍜 비유로 설명: "라면 공장"🥣 Spring Boot 3.2 (옛 구조)**HttpSecurityConfiguration**이 먼저 출근해요"물 끓이고, 면 넣고, 스프 넣고" 직접 다 해요마지막에 포장(= SecurityFilterChain)도 본인이 함즉, 한 사람이 보안 설정 전체를 다 하는 구조🍱 Spring Boot 3.5 (새 구조)**WebSecurityConfiguration**이라는 총괄 매니저가 먼저 출근이 사람이 여러 명의 담당자 (HttpSecurity 설정)에게 일을 시켜요그리고 포장은 SecurityFilterChain으로 조립해서 내보냄즉, 분업된 구조 — 공장은 커졌고, 매니저가 통제함 🔍 왜 이런 변화가 있었을까?이유설명설정이 너무 복잡해졌음HttpSecurityConfiguration 혼자 하다 보니 커지고 유지보수가 어려움커스터마이징이 어려웠음사용자 정의 체인 추가가 어렵고 제한적이었음다중 체인 지원 부족API별 다른 보안 적용이 힘들었음 (/api/**, /admin/**)새 구조가 더 유연SecurityFilterChain을 빈으로 만들면 순서, 조건, 분리 모두 명확해짐🧠 구조 비교 요약항목Spring Boot 3.2 (Security 6.2)Spring Boot 3.5 (Security 6.3)먼저 실행HttpSecurityConfigurationWebSecurityConfiguration중심 클래스HttpSecurityConfigurationWebSecurityConfiguration책임 방식거의 혼자 다 함분업 (매니저 + 여러 체인)구성 방식내부적으로 HttpSecurity 설정외부에서 SecurityFilterChain 등록유연성다중 체인 어려움다중 체인, 조건부 설정 매우 쉬움✅ 결론Spring Boot 3.2에서는 여전히 옛 구조(약간의 WebSecurityConfigurerAdapter 잔재)를 끌어와서→ HttpSecurityConfiguration이 보안 설정의 진입점 역할을 했고,Spring Boot 3.5에서는 완전 리팩토링된 구조라서→ WebSecurityConfiguration이 보안 설정의 시작점(매니저)이 되었어요.

안녕하세요,  수업 내용을 보면 6:00 시간대의 수업자료를 보면 SecurityConfigurer에서 init(B Builder), configure(B builder)을 호출한다고 나와있습니다. 하지만, 실제 소스코드를 보면 아래와 같은데, 파라미터를 보면 Builder 타입이 아닌, 파라미터를 넘기지 않는 것을 확인할 수 있습니다.@Override protected final O doBuild() throws Exception { synchronized (this.configurers) { this.buildState = BuildState.INITIALIZING; beforeInit(); init(); this.buildState = BuildState.CONFIGURING; beforeConfigure(); configure(); this.buildState = BuildState.BUILDING; O result = performBuild(); this.buildState = BuildState.BUILT; return result; } }확인 부탁드려도 될까요?감사드립니다.

안녕하세요.먼저 강의 제작해주셔서 감사합니다!많은 도움 되고 있습니다. 메타 주석 부분에 사실 expression이 없어서 제가 이해하기로는 타입 추론으로 값을 넣는 것 같습니다.그럼 결국 @AuthenticationPrincipal에서도 expression이 없어도 동작하는게 맞을까요? 감사합니다.

안녕하세요"인가 설정 실시간 반영하기" 코드에서 동시 세션 제어 기능을 추가할려고 합니다.http.sessionManagement(session -> session .maximumSessions(1) .maxSessionsPreventsLogin(true) )위 코드를 추가한 후 REST 방식으로 로그인후 로그아웃을 하면 SessionRegistry의 principals 객체에 있는 정보가 삭제되지 않아 다시 로그인을 시도하면 인증오류가 발생합니다.로그아웃을 할 경우 SessionRegistry.removeSessionInformation(sessionId)가 호출되어 principals 정보가 삭제되어야 할 것 같은데 제가 잘못 이해하고 있는 지 궁금합니다. 

localhost:8080 에서 login 페이지로 넘어가고, 로그인을 하면, error?cutomerParam=y 주소로 넘어갑니다. 리다이렉트는 문제없이 잘 된거 같은데 어디서 에러가 생격서 savedRequest 객체에 error가 저장되는지 도통 모르겠네요;; 로그인 직후 network

안녕하세요, 궁금한점 이있는데 33~34 강의 편에서 보면 공격자가 세션 쿠키를 희생자의 브라우저에 삽입해서 희생자가 로그인하면 공격자도 희생자의 정보를 탈취하는 그런 내용의 강의가 있었는데요, 궁금한 점은 공격자는 왜 로그인 같은 기타 인증을 하지 않고 기본적으로 세션 쿠키가 생성이 되어있는걸까요? SessionCreation policy 가 always 가 아니고 if required 였던거 같은데 왜 이미 생성되어 있던 것인지 궁금합니다.

안녕하세요. 강의 잘 보고,듣고, 익히고 있습니다!customAuthenticationFilter관련 부분보다가 궁금증이 생겨서 질문 남깁니다. authenticationManager, authenticationProvider 로직을 SecuriyConfig의 필터가 아닌 일반 서비스 로직 내부에서도 똑같이 커스텀해서 사용이 가능한가요? (Contoller에서 dto로 받아서 서비스에서 id/pw 검증 후 이후 과정을 처리하는 그런 흐름이 가능한건지 궁금합니다) jwt 관련 로그인을 구현하려고 하는데, 전체적인 구조는 SpringSecurity의 맥락을 그대로 가져가고 싶은..생각입니다.

 HttpSecurity에서 가져오는 AuthenticationManagerBuilder와주입받는 AuthenticationManagerBuilder가 사로 다르지만 타입이 같아 메서드는 똑같을텐데 managerBuilder.authenticationProvider(new DaoAuthenticationProvider()); builder.authenticationProvider(new DaoAuthenticationProvider());후자일경우 수업 내용처럼부모 프로파이더에는DaoAuthenticationProvider() 가 들어가고providers 에는 커스텀과 익명 프로바이더 2개가 들어가는데요 전자 즉 직접 참조하는 AuthenticationManagerBuilder는부모 프로바이더는 null 인데 반해 기존 providers 에 생겨서 총 3개가되고있습니다 물론 실제 실행할때에는 똑같은 결과지만 함수authenticationProvider 은 public AuthenticationManagerBuilder authenticationProvider(AuthenticationProvider authenticationProvider) { this.authenticationProviders.add(authenticationProvider); return this; }인데 왜 각각의 작동이 다른지 궁금합니다   

UserDetailsService()을 커스텀으로 만든 후에 UserDetail이 아닌 타입을 반환할 수 있나요? 아니면 UserDetail의 멤버변수들 뿐 아니라 더욱 많은 멤버 변수들을 추가해서 사용해도 문제가 없나요?

스프링 부트 3.4.3, 스프링 시큐리티 6.4.3 기준입니다.다음과 같이 설정하게 되면 api/**는 적용되지 않고 oauth/**에만 적용됩니다.http.securityMatchers(matchers -> matchers.requestMatchers("/api/**") ) .securityMatchers(matchers -> matchers.requestMatchers("/oauth/**") );

만약에 CustomProvider를 빈으로 정의한다면 DAOProvider를 저희가 만든 CustomProvider 가 대체하는것으로 이해 했는데 그렇게 되면 저희가 빈으로 정의한 UserDetailsService는 사용하지 않는건가요?

강의 내용 중에 POST 와 같이 데이터를 변경하는 요청의 경우 csrf 토큰을 생성한다는 내용이 있는데 로그인 페이지 요청시 GET 으로 요청하는데 csrf 토큰이 input 태그에 포함되어 있는 걸로 보아  POST 와 같이 데이터틀 변경하는 요청의 경우 csrf 토큰을 생성하는 게 아니라 csrf 토큰을 검증하는 것이고, csrf 토큰은 모든 요청에 대해 반환해준다가 맞을까요?  또 csrf 토큰이 난수를 조합해 계속 변경해서 클라이언트에 반환한다고 들었는데제가 잘못 본 건지 모르겠지만 토큰을 디코딩할 때난수를 조합하는 코드를 보면 토큰의 길이로 난수를 만드는 것 같은데,토큰의 길이로 난수를 만든다고 하면토큰을 변하게 하지 않는 이상 인코딩된 토큰의 결과가 똑같을 것 같거든요.  그래서 세션당 고유 토큰 값은 똑같다고 한다면로그인 전에는 클라이언트에 반환하는 토큰이계속 바뀌고 (=익명 사용자 세션이니)로그인 이후에는 클라이언트에 반환하는 토큰이 일정한 게 아닐까 하는 물음이 생겼습니다.어느게 맞는 걸까요 ?

안녕하세요. 강사님 실습을 하던 중 강의 17:00에 보이는 갯수와 달리3개밖에 안보입니다. 어떤 차이 때문에 11개가 보이지 않는 것인지 궁금합니다.