스프링 시큐리티
-인증/인가 관리
인증 인가란 무엇인가?
인증- 해당유저가 실제 유저인지
ex- 지문인증,face ID
인가- 유저에게 특정 리소스에 대한 접근을 허락(인가)
ex - 관리자 페이지
웹 애플리케이션의 인증
일반적으로 서버---(http로 통신)---클라이언트 구조
http 통신 -> 비 연결성 무상태
비 연결성: 서버 <--X--> 클라이언트 (직접적으로 연결X)
무상태 : 서버가 클라이언트의 정보를 저장X
-> 서버의 비용 ↓ 리소스 ↓
그럼 어떻게 그 동안 연속성있게 (로그인 유지한채로 페이지 이동) 사용해왔나?
쿠키-세션 방식
유저의 인증과 관련된 최선의 정보는 저장해서 로그인 유지
1. 사용자가 로그인 요청을 보냅니다.
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조해봐야겠죠?
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 “세션 저장소”에 해당 유저가 로그인 되었다는 정보를 넣습니다.
4. 세션 저장소에서는 유저의 정보와는 관련 없는 난수인 session-id를 발급합니다.
5. 서버는 로그인 요청의 응답으로 session-id를 내어줍니다.
6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관하고 앞으로의 요청마다 세션아이디를 같이 보냅니다. (주로 HTTP header에 담아서 보냅니다!)
7. 클라이언트의 요청에서 쿠키를 발견했다면 서버는 세션 저장소에서 쿠키를 검증합니다.
8. 만약 유저정보를 받아왔다면 이 사용자는 로그인이 되어있는 사용자겠죠?
9. 이후에는 로그인 된 유저에 따른 응답을 내어줍니다.
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조해봐야겠죠?
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 “세션 저장소”에 해당 유저가 로그인 되었다는 정보를 넣습니다.
4. 세션 저장소에서는 유저의 정보와는 관련 없는 난수인 session-id를 발급합니다.
5. 서버는 로그인 요청의 응답으로 session-id를 내어줍니다.
6. 클라이언트는 그 session-id를 쿠키라는 저장소에 보관하고 앞으로의 요청마다 세션아이디를 같이 보냅니다. (주로 HTTP header에 담아서 보냅니다!)
7. 클라이언트의 요청에서 쿠키를 발견했다면 서버는 세션 저장소에서 쿠키를 검증합니다.
8. 만약 유저정보를 받아왔다면 이 사용자는 로그인이 되어있는 사용자겠죠?
9. 이후에는 로그인 된 유저에 따른 응답을 내어줍니다.
JWT 기반 인증
인증에 필요한 정보-> 암호화 토큰 이 토큰가지고 인증
1. 사용자가 로그인 요청을 보냅니다.
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조해봐야겠죠?
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 유저의 정보를 JWT로 암호화 해서 내보냅니다
4. 서버는 로그인 요청의 응답으로 jwt 토큰을 내어줍니다.
5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보냅니다.
6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증합니다.
7. 이후에는 로그인 된 유저에 따른 응답을 내어줍니다.
2. 서버는 DB의 유저 테이블을 뒤져서 아이디 비밀번호를 대조해봐야겠죠?
3. 실제 유저테이블의 정보와 일치한다면 인증을 통과한 것으로 보고 유저의 정보를 JWT로 암호화 해서 내보냅니다
4. 서버는 로그인 요청의 응답으로 jwt 토큰을 내어줍니다.
5. 클라이언트는 그 토큰을 저장소에 보관하고 앞으로의 요청마다 토큰을 같이 보냅니다.
6. 클라이언트의 요청에서 토큰을 발견했다면 서버는 토큰을 검증합니다.
7. 이후에는 로그인 된 유저에 따른 응답을 내어줍니다.
JWT는 뭐노?
말 그대로 암호화 시킨 토큰이고
헤더,페이로드,베리파이 시그니처로 나누어지고
페이로드에 유저의 정보가 저장되어있고 나머지는 암호화 관련 정보양식 (어케 암호화 했노?)
