전통적인 인증 방식
이전에는 클라이언트가 다양하지 않았음. 인터넷하나에만 보내줬기에 세션과 쿠키를 자주 사용했다.
근데 기기가 모바일도 생기고 패드도 생기고 이래저래 늘어나면서 쿠키 세션을 공유하기 힘들어졌다
좀 더 최신화된 방식 (토큰)
그래서 요즘은 인증 절차를 토큰으로 하는데,
1. 로그인할 때 유저 정보를 보내면 이 정보를 바탕으로 토큰을 만들어서 클라이언트에게 전달한다.
2. 그럼 다른 요청을 보낼때, 클라이언트는 토큰을 같이 실어서 이것좀 해줘~ 하면 서버에서 들어온 토큰과 유저의 토큰을 비교해보고 맞으면 서비스를 제공한다.
좀 더 구체적으로
JWT(Json Web Token)
정보를 비밀리에 전달하거나, 인증할 때 주로 사용하는 토큰, Json객체를 이용한다.
이런 구조로 이루어져 있다.
- 헤더 (Header)여긴 어떤 알고리즘으로 암호화 할지, 어떠한 토큰을 사용할 것인지에 대한 정보를 담는다.
- 정보 (Payload)전달하려는 정보(Claim이라 부른다.) 개인정보(주민,이름,주소)등을 제외한 유저 아이디, 비밀번호 같은 것들이 담긴다. 수정이 가능하기에 뭘 담을 지는 자유다.
- 서명 (Signature) Header+Payload를 합친 후 지정한 secret key로 암호화 시켜서 토큰을 변조하기 어렵게 만들어 준다.
요렇게 사용된다.
우선 토큰이 발급되면 만료될 때까지, 클라이언트는 대부분의 api 요청시 헤더에 토큰을 실어 보내고, 서버에서는 이를 검증한다.
구축법
요렇게 클래스 하나 잡아 놓고,
jwt 처리를 해준다.
필요한 처리들 해주고 인증관련 헤더가 없거나, 여기 안에 토큰이 유효 하지 않거나 그런 .. 것들 해주고
웹플럭스에선 servlet안쓴다고 하셨다 선생님이
내 영혼의 선생님이다 이 강의를 하시는분
로그인과 회원가입을 제외한 다른 모든 api 요청에는 필터를 적용시켜주면 된당!
'MSA(마이크로 서비스 아키텍처)' 카테고리의 다른 글
| 베포시 크레덴셜과 api key (0) | 2023.08.09 |
|---|---|
| 젠킨스 시작 비밀번호 (0) | 2023.08.04 |
| swap 메모리 (0) | 2023.08.04 |
| Jenkins, Docker in Docker, Docker out of Docker (2) | 2023.08.04 |
| docker: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by docker) (0) | 2023.08.03 |
