Spring security - Authorization

Spring Projects

 

종류: Spring FrameWork에서 발전했다. 이렇게 많다.

 Spring Security: 웹 어플이나. Rest api에 인증, 권한을 추가하는 경우

 Spring Data: 다른 타입의 데이터베이스를 통합하는 경우

 Spring integration: 다른 어플리케이션과의 통합 관련 문제를 도와주는 프로젝트

 Spring Boot: microservice를 빌드해주는 유명한 프레임워크(프로젝트)

 Spring Cloud: 스프링 네이티브 애플리케이션을 빌드해주는 프로젝트

 

스프링 에코 시스템이 유명한 이유

느슨한 결합: 빈과 의존성의 연결을 느슨하게 해서 유지 보수가 쉽다.

Reduced Boilerplate Code (상용구 코드 줄여줌): 비즈니스 로직에만 집중할 수 있게 해준다. (확인된 예외는 모두 런타임 또는 Unchecked Exception으로 반환하기 때문에 exception handling 불요, 코드의 양을 줄여준다.)

Architectural Flexibility: Spring Modules and Projects(원하는 프로젝트, 모듈만 뽑아 쓸 수 있다)

계속 발전하고 있다. (솔직히 안전함을 빌미로 뭔가 자유를 희생하는 느낌이 드는 것 같은 프레임워크라는 생각을 지울 수 없다)

---

 Spring Security

 

인코딩 vs 해싱 vs 암호화

 

    인코딩: transform data – 키나 패스워드 사용 x, 데이터보안에 적합 x (데이터의 효율적 전송, 저장 목적)

 

    해싱: 해싱해서 해시 String으로 바꿈. 복호화 불가능. (데이터 무결성 검증하는 것이 목적, 비밀번호 저장) – SHA-256 안전하지 않음 why? 요즘 기술이 좋아가지고 금방 푼다.

 

    인크립션(암호화): key나 password를 이용해서 암호화/복호화가 가능하다. 암호화/ 복호화를 위해서는 키나 패스워드가 필요함. 키나 패스워드를 이용한 디코딩 알고리즘을 통해 텍스트를 구할 수 있음 (데이터 보호 목적)

 

Spring security Authentication의 이해

인증은 spring security 필터 체인의 일부로서 이루어진다.

요청이 유입될때마다 spring security가 이걸 가로채고 필터체인이 실행됨. 그 필터의 일부로서 인증확인이 이루어짐

 

인증 순서

 

1.     AuthenticationManager – 인증을 담당하는 인터페이스

 

2.     AuthenticationProvider – 특정한 인증 타입을 제공하는 인터페이스 (spring security에서는 다양한 타입의 authenticationProvider가 동시에 작동하고있음)

ex) JwtAuthenticationProvider – JWT Authentication에 대한 인증타입 제공

 

3.     UserDetailService - AuthenticationProvider들이 대화하는 인터페이스, 유저 데이터를 로드하는 핵심 인터페이스, username에 해당하는 데이터를 받아서 이를 AuthenticationProvider에 제공, AuthenticationProvider는 detail, 세부정보를 받아서 credencial과 비교하여 확인한다. 이게 성공하면 principal 과 authentication도 Authentication에 채워넣는다.

 

4.     인증에 성공하면 결과는 어디 저장? SecurityContextHolder에 저장 그 안에는 SecurityContext가 있고 거기에 Authentication이 저장된다. 요청이 도착하면 거기는 Authentication안에는 credential 만 있다. AuthenticationManager가 요청을 인증하면 그제서야 Principal과 authority도 있다.

 

Spring security에서 Authentication은 3가지 것들을 의미함.

Authenticate() 메서드가 호출되기 전에는 Authentication에는 credencial만 포함

이 credencial이 유효한지 알기 위해서 AuthenticationManage는 수많은 AuthenticationProvider들과 상호작용을 함

 

 

Authenticate 메서드가 성공하면 (인증에 성공하면), 주체와 권한도 포함하게 됨

a.     Credencial, 자격증명. Userid와 password

b.     Principal, 사용자에 대한 세부 정보(나이, 주소 등)

c.     Authorities: 주체가 가지고 있는 role과 Autorities

 

이러고 나서 만약에 로그인을 한다고 하면 return 해주는 값은 그냥 토큰 그 자체일텐데, 어디 뭐 쿠키에다가 저장하나? 싶었다. 근데 REST API는 따로 세션이 있거나 하지 않기 때문에 React의 경우 그냥 react단 쿠키에 저장하지 않을까,. 라는 생각을 했다.

근데 뭐 로컬스토리지나 세션스토리지에 저장한다고 한다.

이렇게 되면 요청할 때마다 header에 bearer 토큰을 일일이 보내줘야 하지 않을까 싶다.