묻고 답해요
156만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결스프링 시큐리티 OAuth2
Resouce owner 인증 전 단계 질문입니다.
클라이언트가 인가서버에게 인가코드를 요청하기 전에 사용자인증을 받기 위해 사용자 id, 비밀번호를 입력하는 단계가 먼저 거치고, 인증이 되면 인가서버에게 /oauth2/authorize url로 response_type=code ~~ 이런식의 정보를 포함해서 요청하게 되는데 그러면 사용자가 인증받을때 입력한 사용자 id, 비밀번호를 통해 인증처리를 하는건 인가서버에서 하는게 아닌건가요? 인가서버에서 하는거라면 입력한 사용자 id, 비밀번호는 어떤 필터에서 처리하는건가요?
-
미해결스프링 시큐리티 OAuth2
code 를 accessToken 으로 교환시 질문입니다.
인가서버로부터 code 발급받고 이 코드를 accessToken으로 교환하기 위해 서버에 요청할때 이 순간은 인증을 못받은 상태 아닌가요? accessToken을 발급받아야 클라이언트가 인증을 받은거고 그리고 이때도 클라이언트가 인증을 받아서 authorizedClient 객체가 생기는거지 인증객체가 생기는건 아닐텐데 강의 37분30초쯤에는 code를 accessToken으로 바꿔달라는 요청할때 왜 인증객체가 생성돼있나요? authorization server api를 사용했기때문에 마지막에 위치한 인가서버 필터에 도달하기 위해 다르게 처리되는건가요?
-
미해결스프링 시큐리티 OAuth2
resouce server 질문
인가서버 설정을 하면서 인가서버에서 accessToken을 받고 이를 검증해야하기 때문에 oauth2ResourceServer api를 jwt로 설정한다고 설명하셨는데 이게 무슨 말인지 잘 모르겠습니다. oauth2ResourceServer 는 말그대로 헤더에 jwt 토큰이 있는 요청이 들어오면 이 jwt 토큰을 인가서버와의 통신으로 검증해서 인증처리를 하는 구조인건데 인가서버 설정에서 이게 왜 필요한건지 잘 모르겠습니다. user info 요청할때 클라이언트가 인가서버로 accessToken을 주면서 유저정보 달라고할때 인가서버에서 이 accessToken을 검증하는데, 이때 리소스 서버를 사용해서 검증한다는건가요? 그럼 oauth2ResourceServer api를 등록안하면 인가서버는 자체적으로 accessToken을 검증할수가 없는건가요? 인가서버와 리소스서버는 서로 다른 개념인거 같은데 인가서버를 위해 리소스서버를 써야한다는게 잘 이해가 가지 않습니다.
-
미해결스프링 시큐리티 OAuth2
자체로그인 구현시 질문입니다.
카카오, 네이버같은 소셜로그인이 아닌, 자체 로그인을 통한 검증을 구현하려고 하는데 프론트가 react 이므로 jwt 토큰을 사용한 검증을 진행하려고 합니다. 그러면 이를 구현하기 위해서 jwt 토큰을 발급하는 oauth2 authorization server와 발급한 jwt토큰을 검증하는 oauth2 Resource Server와 자체적으로 만든 시큐리티 인가서버에 code와 토큰을 요청하는 oauth2 client api를 전부 사용해야하는건가요? 즉, jwt를 통한 자체로그인 검증기능을 구현하려면 지금까지 학습한 oauth2 client + oauth2 Resource Server + oauth2 Authorization Server 3개 api를 전부 사용해 구현해야 하는건가요?
-
미해결스프링 시큐리티 OAuth2
CustomAuthenticationProvider 질문
http://localhost:9000/oauth2/authorize?response_type=code&client_id=oauth2-client-app1&scope=openid%20read%20write&redirect_uri=http://127.0.0.1:8081형태에 첫 로그인 요청을 했을때, 로그인 페이지로 가지 않는 현상이 있습니다.=> 확인을 해봤을때, CustomAuthenticationProvider 에서 프로세스 진행 완료 후 principal = AnonymousAuthenticationToken [Principal=anonymousUser, Credentials=[PROTECTED], Authenticated=true, Details=null, Granted Authorities=[ROLE_ANONYMOUS]]principal 까지 확인되었습니다. 그 다음 추가적인 내용을 확인해봐야될 내용이 어떤 걸 까요?추가적으로 첫 요청에 따른 redirect 하는 클래스가 어디인지 알고 싶습니다.
-
미해결스프링 시큐리티 OAuth2
인증과정 질문입니다.
이전 챕터중 OAuth2Login api를 사용했을때는 인가서버로부터 accessToken을 받은후 인증처리를 하기 위해서 다시 인가서버에 userinfo endpoint로 요청을 보내서 유저정보를 가져오고 이 정보를 바탕으로 OAuth2User 객체를 만들어서 인증객체를 만들고 인증과정을 완료했습니다. 근데 지금 ResouceServer api를 사용했을때는 accessToken, 즉 jwtToken 만으로도 인증객체를 만들고 인증처리를 완료하는데 그러면 이전에는 accessToken을 받고 왜 이것만으로 인증처리를 완료하지 않은건가요?
-
미해결스프링 시큐리티 OAuth2
최초로그인 -> 로그아웃 후 다시 로그인 시 질문
처음 서버 run 하고 google, naver, keycloak 전부 처음에는 아이디, 비밀번호를 입력하는 사용자입력이 필수적인데, 한번 로그인하고 나서는 웹어플리케이션 서버를 종료하고 다시 시작해도 구글, 네이버, keycloak 계정으로 로그인하는 과정이 필요없이 바로 인증이 됩니다. 왜이런건가요? 로그아웃했으면 당연히 다시 로그인하는 과정이 필요한데 이러면 잘못된거 아닌가요?
-
미해결스프링 시큐리티 OAuth2
정적 리소스 파일 설정 질문입니다.
application.yml에서 마지막에 web : static-path-pattern: /static/**이걸 안하면 static 폴더 아래에 있는 정적 리소스 파일이 html파일에 적용이 안되는데 왜이런건가요? 이전에는 해당 코드가 yml에 없었어도 제대로 됐었던것같은데 이유가 뭔가요? 그리고 정적 리소스 파일의 디폴트값은 원래 /static 아닌가요?
-
미해결스프링 시큐리티 OAuth2
클라이언트 인가 후 저장 질문
클라이언트가 인가서버로부터 인가를 받으면 authorizedClient가 생성되는데, 이 생성된 authorizedClient는 세션에 저장돼서 다음 요청일때 이 세션에서 객체를 가져와 인가처리된 클라이언트인지 아닌지 확인하는건가요? 마치 인증완료후 authentication 객체가 securityContext에 저장되고, 이 컨텍스트가 세션에 저장되는것처럼 작동하는건가요?
-
미해결스프링 시큐리티 OAuth2
authentication server 토큰 검증 api 테스트 질문
현재 /oauth2/token 에 접근하지 못하는 문제가 있는 것으로 보입니다.제가 확인해봐야할 내용이 어떤게 있을까요?동영상에서 37:33쪽에 있는 내용하고 비교를 해봤을 때, 현재로썬 authenticated 가 다르다게 진행이 되고 있어서 질문드립니다.
-
미해결스프링 시큐리티 OAuth2
인증처리에서 SecurityContext 질문입니다.
컨트롤러에서 직접 사용자 인증처리를 구현하는데 마지막에 Oauth2AuthenticationToken을 SecurityContextHolder를 사용해 securityContext에 저장하는데, 이 처리는 이번 요청이 끝나면 securityContext가 초기화되므로 securityContext를 세션에도 저장해줘야 하는거 아닌가요?
-
미해결스프링 시큐리티 OAuth2
로그인 인증 후 처리 질문입니다.
처음 로그인 인증처리받을때는 인가서버로부터 code를 받기 전에 유저의 동의가 필요하므로 유저가 아이디, 비밀번호를 입력하는 과정이 필요합니다. 그리고 이후 로그인 인증처리 완료되면 서버 세션에 SecurityContext 가 저장되고 인가서버에도 해당 유저의 세션이 저장되고 인증처리가 끝납니다. 근데 서버를 종료하고 재시작하면 서버의 세션이 초기화되므로 인증처리가 처음부터 다시 시작해야 될거같은데 서버 종료 후 다시 인증처리 받기 시작할땐 유저가 아이디, 비밀번호를 입력하는 과정 없이 authorizationEndpoint로 인가서버에 요청하기만 하면 인증과정이 성공합니다. 이유가 뭔가요?
-
미해결스프링 시큐리티 OAuth2
인증성공 후 로직 질문입니다.
지금 처음 인증성공받을때 인가서버로부터 accessToken 발급받고 이 토큰으로 유저정보 가져와서 인증성공후 securityContext, 세션에 저장합니다. 그리고 인증성공받은 이후에는 그러면 인증받았는지 안받았는지는 세션에서 SecurityContext 객체를 가져와서 인증여부를 체크하는건가요? 그렇다면 OAuth2 사용하지않고 그냥 Spring Security만 사용했을때랑 차이가 처음 인증과정만 달라지는거고 이후에는 똑같이 인증객체를 세션에 저장해서 사용하는거니까 인증후에는 로직이 똑같은건가요?
-
미해결스프링 시큐리티 OAuth2
logoutHandler 질문입니다.
로그아웃 api 설정에선 logoutSuccessHandler, invalidateHttpSession, clearAuthentication, deleteCookies 만 설정했는데 logoutFilter에 왜 인가서버에 로그아웃을 요청하는 logoutHandler가 있는건가요? OAuth2 라이브러리 의존성 추가하면 자동으로 추가되는건가요? 맞다면 logout api설정으로 먼저 클라이언트에서 세션, 쿠키, 인증 객체를 제거하고 이후 인가서버에서 해당 유저의 세션을 제거하는 logoutHandler가 호출돼서 인가서버에서 세션 삭제하고, 로그아웃 성공했으니 logoutSuccessHandler에서 설정한 RedirectUri로 이동하는건가요? 아니면 클라이언트에서 인증정보 제거후 logoutSuccessHandler에 설정한 객체가 호출돼고 이 Handler에서 인가서버에 세션제거하고 redirect하게 하는건가요?
-
미해결스프링 시큐리티 OAuth2
openid 질문입니다.
Scope 에 openid 가 포함되어 있으면 OidcAuthorizationCodeAuthenticationProvider 를 호출하고 아니면 OAuth2AuthorizationCodeAuthenticationProvider 를 호출하도록 제어된다고 돼있는데, 최신버전의 keycloak에선 scope에 openid가 없으면 에러가 발생하도록 돼있어서 반드시 openid를 포함시켜줘야 하는데, 그러면 인가서버로 keycloak 쓸때는 OidcAuthorizationCodeAuthenticationProvider 가 호출된다고 보면 되겠네요?
-
미해결스프링 시큐리티 OAuth2
스프링시큐리티 기본 제공 password 질문입니다.
프로젝트 의존성에 implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'즉, oauth2 의존성을 추가하면 프로젝트 실행시 콘솔에 스프링 시큐리티가 기본으로 제공하는 password가 안나오는데 oauth2 의존성을 제거하고 실행해보면 기본으로 제공하는 password가 콘솔에 나옵니다. 강의랑 다른거 같은데 이유가 뭘까요? 최신버전에 따른 차이인가요?
-
미해결스프링 시큐리티 OAuth2
JwtDecoder 문제
org.springframework.boot:spring-boot-starter-oauth2-resource-server:2.7.3 버전에서 jwtDecoder 생성 문제가 있는 것으로 보입니다.jwt-set-uri 설정일때는 되지 않고 issuer-uri 설정일때만 문제가 발생하지 않습니다.혹시 제가 설정 문제인지 확인 차 질문드립니다.url 확인도 해봤습니다. https://github.com/okta/samples-java-spring/issues/77여기서 문제가 있다며, 일부분을 인정을 하였습니다.같은 상황으로 보입니다.
-
미해결스프링 시큐리티 OAuth2
authenticationEntryPoint 질문입니다.
강의 10분22초 강의자료 그림에서 인증이 실패하면 DaoAuthenticationProvider가 BasicAuthenticationEntryPoint를 호출한다고 돼있는데, AuthenticationEntryPoint는 이 과정에서의 실패가 아니라 해당 필터를 지나서 AuthorizationFilter에서 인증이 안된 사용자가 권한으로 인해 예외가 발생했을 경우 호출되는거 아닌가요? UsernameAuthenticationFilter에선 이런식이였던거 같은데 제가 잘못 이해한걸까요? DaoAuthenticationProvider에서 인증이 실패하면 BasicAuthenticationEntryPoint가 아니라 해당 필터에 등록된 FailureHandler가 호출되야할거 같은데 설명 부탁드립니다!
-
미해결스프링 시큐리티 OAuth2
rsa 512 복호화 에러
org.springframework.security.oauth2.jwt.BadJwtException: An error occurred while attempting to decode the Jwt: Signed JWT rejected: Invalid signature at org.springframework.security.oauth2.jwt.NimbusJwtDecoder.createJwt(NimbusJwtDecoder.java:180) ~[spring-security-oauth2-jose-5.7.3.jar:5.7.3] at org.springframework.security.oauth2.jwt.NimbusJwtDecoder.decode(NimbusJwtDecoder.java:137) ~[spring-security-oauth2-jose-5.7.3.jar:5.7.3] at io.security.oauth2.resource.server.filter.authorization.JwtAuthorizationRsaPublicKeyFilter.doFilterInternal(JwtAuthorizationRsaPublicKeyFilter.java:38) ~[classes/:na] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:223) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter.doFilter(AbstractAuthenticationProcessingFilter.java:217) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:103) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:89) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.header.HeaderWriterFilter.doHeadersAfter(HeaderWriterFilter.java:90) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:75) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:112) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:82) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:55) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.session.DisableEncodeUrlFilter.doFilterInternal(DisableEncodeUrlFilter.java:42) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:346) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:221) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:186) ~[spring-security-web-5.7.3.jar:5.7.3] at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:354) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:267) ~[spring-web-5.3.22.jar:5.3.22] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201) ~[spring-web-5.3.22.jar:5.3.22] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117) ~[spring-web-5.3.22.jar:5.3.22] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:189) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:162) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:197) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:135) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:360) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:399) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:890) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1789) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.65.jar:9.0.65] at java.base/java.lang.Thread.run(Thread.java:829) ~[na:na]Caused by: com.nimbusds.jose.proc.BadJWSException: Signed JWT rejected: Invalid signature at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:378) ~[nimbus-jose-jwt-9.22.jar:9.22] at com.nimbusds.jwt.proc.DefaultJWTProcessor.process(DefaultJWTProcessor.java:303) ~[nimbus-jose-jwt-9.22.jar:9.22] at org.springframework.security.oauth2.jwt.NimbusJwtDecoder.createJwt(NimbusJwtDecoder.java:154) ~[spring-security-oauth2-jose-5.7.3.jar:5.7.3] ... 57 common frames omitted이런 에러가 발생하고 있습니다. 이유를 잘 모르겠습니다.
-
미해결스프링 시큐리티 OAuth2
스피링 시큐리티 강의 너무 좋습니다
시큐리티 강의를 만들어주셔서 너무 감사합니다!디버깅을 통한 내부 아키텍처 동작원리 이해가 너무재밌습니다 ㅎㅎ 시큐리티에 대한 거부감이 초반에 있었지만, 스프링 시큐리티 동작원리를 이해하게 되므로써 시큐리티가 재밌어지고 활용도 잘할것 같습니다. 그리고 내부 디버깅을 하면서 느낀게 코드 디자인 설계 특히 디자인 패턴에 대해서도 많이 공부할 수 있게되어서 좋은 공부 방향인것 같습니다 ㅎㅎ 다시한번 감사의 말씀을 드립니다.