access token과 refresh token을
어디에 저장하는게 best practice라고 생각함?
매번 얘기가 달라지는데 종결시켜주셈
클라가 안전하게 보관하는거 아님? 그게 무슨 떡밥이 있는지 링크 좀
이걸 왜고민하지.. 그때그때 다르겠지만 한번 발급하면 클라에서 갖고있으면되는걸 - dc App
클라에서 어디에 갖고있어야함
리프레쉬토큰을 더 안전한곳에 보관해라 이런 얘기 있긴한데 큰 의미 없다고 생각함. 매번 리프레시토큰 꺼낼때마다 사용자 지문인증받는것도 아니고. 클라쪽 문제로 액세스토큰 털리면 리프레쉬토큰도 털렸다 생각해야
그래서 어디에 보관해야함? 쿠키? 메모리?
프론트에서 보관하면 됨. - dc App
쿠키? 메모리?
그냥 jwt 쓰지마. 99%의 서비스는 그냥 세션 쓰는게 낫다. - dc App
ㄹㅇ 특별히 jwt써야하는 상황아니면 걍 세션쓰지 왜 jwt고집하는지모르겟다
1%는 어떤 경우임?
JWT를 사용할 때 인증 서버와 리소스 서버가 분리된 환경 확장성이 중요한 마이크로서비스 아키텍처 서버 상태를 유지하지 않고(stateless) 클라이언트에서 관리하도록 할 때 - dc App
해당 댓글은 삭제되었습니다.
메모리에 저장하면 xss에 대한 방지책은??
하아 고수만 댓글달라구요.. xss가 쿠키에 저장해서 생기는 문제라니ㅋㅋ
ㄴ 어줍잖게 주워들은 지식으로 남들 이겨먹으러고 하지마라 - dc App
HttpOnly 걸면 자바스크립트로는 해당 쿠키에 접근 못하지 않음? 둘 다 HttpOnly 걸고 쿠키에 저장하면 되지
고수고 나발이고 이게 왜 떡밥인지 모르겠네 로그인 달면 당연히 SSL 달테니까 위에 118말 처럼 하면 된다
http only 쿠기 걸고 타 api에 직접 토큰 쏴보내야하면 1차 프록시 백엔드를 통해 간접 호출해서 전달. 난 이렇게 사용함.
프록시 백엔드가 없는 환경이면 파이팅해라 ㅎ
클라가 안전하게 보관하는거 아님? 그게 무슨 떡밥이 있는지 링크 좀
이걸 왜고민하지.. 그때그때 다르겠지만 한번 발급하면 클라에서 갖고있으면되는걸 - dc App
클라에서 어디에 갖고있어야함
리프레쉬토큰을 더 안전한곳에 보관해라 이런 얘기 있긴한데 큰 의미 없다고 생각함. 매번 리프레시토큰 꺼낼때마다 사용자 지문인증받는것도 아니고. 클라쪽 문제로 액세스토큰 털리면 리프레쉬토큰도 털렸다 생각해야
그래서 어디에 보관해야함? 쿠키? 메모리?
프론트에서 보관하면 됨. - dc App
쿠키? 메모리?
그냥 jwt 쓰지마. 99%의 서비스는 그냥 세션 쓰는게 낫다. - dc App
ㄹㅇ 특별히 jwt써야하는 상황아니면 걍 세션쓰지 왜 jwt고집하는지모르겟다
1%는 어떤 경우임?
JWT를 사용할 때 인증 서버와 리소스 서버가 분리된 환경 확장성이 중요한 마이크로서비스 아키텍처 서버 상태를 유지하지 않고(stateless) 클라이언트에서 관리하도록 할 때 - dc App
해당 댓글은 삭제되었습니다.
메모리에 저장하면 xss에 대한 방지책은??
하아 고수만 댓글달라구요.. xss가 쿠키에 저장해서 생기는 문제라니ㅋㅋ
ㄴ 어줍잖게 주워들은 지식으로 남들 이겨먹으러고 하지마라 - dc App
HttpOnly 걸면 자바스크립트로는 해당 쿠키에 접근 못하지 않음? 둘 다 HttpOnly 걸고 쿠키에 저장하면 되지
고수고 나발이고 이게 왜 떡밥인지 모르겠네 로그인 달면 당연히 SSL 달테니까 위에 118말 처럼 하면 된다
http only 쿠기 걸고 타 api에 직접 토큰 쏴보내야하면 1차 프록시 백엔드를 통해 간접 호출해서 전달. 난 이렇게 사용함.
프록시 백엔드가 없는 환경이면 파이팅해라 ㅎ