플러터 Authentification 구현하기

Lee_SH 2023. 6. 13. 19:29

Token & Session

Session : 유저의 정보를 DB에 저장하고 상태를 유지하는 도구

특수한 ID값으로 구성 → 어떤 유저인지 표현 해줌(특정 유저와 연동)
서버에서 생성 → 클라이언트에서 쿠키로 저장
클라이언트에서 요청을 보낼때 Session ID를 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서 알 수 있다(ID값은 유저와 연동된 고유한 Key값이므로) → 따라서 요청시마다 매번 아이디와 비밀번호를 물어볼 필요가 없다
서버에서 데이터가 저장되므로 클라이언트의 사용자 정보가 노출될 위험이 없다(장점)
→ 만약 노출이 되더라도 ID자체는 랜덤한 String값일뿐 DB와 대조하지 못한다면 아무런 의미가 없으므로 설령 ID값이 노출이 되더라도 상관이 없다
Session ID는 DB에 저장되기 때문에 요청이 있을때마다 매번 DB를 확인해야한다(단점?) → ID값을 DB와 대조를 해야 유의미한 값을 가지게 되므로
DB에 Session을 저장하므로 Horizontal Scaling(같은 서버를 여러개 수평적으로 늘려 트래픽을 분산시키는것)이 어렵다 → Session이 중복저장되므로

Token : 유저의 정보를 Base64로 인코딩된 String값에 저장하는 도구

Header, Payload, Signature로 구성되어 있으며 Base64로 인코딩(Session과 달리 실제 유의미한 데이터)
서버에서 생성되서 클라이언트에서 저장
클라이언트에서 요청을 보낼때 Token ID를 같이 보내면 현재 요청을 보내는 사용자가 누구인지 서버에서 알 수 있다 → 따라서 요청시마다 매번 아이디와 비밀번호를 물어볼 필요가 없다
Token은 DB에 저장되지 않고 Signature값을 이용해서 검증할 수 있다. 따라서 Session과 달리 검증시마다 DB를 매번 들여다볼 필요가 없다
정보가 모두 토큰에 담겨져있고 클라이언트에서 토큰을 저장하므로 정보 유출의 위험이 있다(단점) → 토큰을 Decoding하면 정보가 모두 보여진다
DB가 필요 없기때문에 Horizontal Scaling이 쉽다

EX) 현재 유저의 장바구니 목록을 가져오고싶은 경우

EX) 현재 유저의 장바구니 목록을 가져오고싶은 경우

→ Session보다 절차를 간소화 할 수 있다는 장점이 있다

Json Web Token의 약자
Base64로 인코딩
Header, Payload, Signature로 구성
- Header : 토큰의 종류, 암호화 알고리즘등 토큰에 대한 메타데이터가 들어있다
- Payload : 발행일, 만료일, 사용자 ID등 사용자 검증에 필요한 정보가 들어있다
- Signature : Header와 Payload를 알고리즘으로 싸인한 값이 들어 있어서 이 값을 기반으로 토큰이 발급된 뒤로 조작되었는지 확인할 수 있다

Secret값이 일치해야함

두 토큰 모두 JWT 기반

Access Token
- API 요청을 할 때 검증용 토큰(누구로 로그인 되어있는 상태인지 알려줌)으로 사용된다. 따라서 인증이 필요한 API를 사용할때는 꼭 Access Token을 Header에 넣어서 보내야한다
Refresh Token
- Access Token을 추가로 발급할때 사용 → 즉, Access Token을 새로고침(Refresh)

→ Access Token은 http 요청등을위해 자주 노출되지만 RefreshToken은 AccessToken을 새로 발급받을경우에만 사용되므로 노출이 적다.

따라서 Access Token은 유효기간을 짧게해서 해커에게 탈취되더라도 오래 사용하지 못하게함

출처 - 코드팩토리 인프런 인강