- 인증
선택한 인증 요건과 관련하여 적합한 자격 증명을 입력하는 사용자에게 기업 시스템에 대한 액세스를 허용
- 인가 ( 권한 부여 )
서비스를 이용할 수 있는 권한을 부여받게 되고 사용자마다 엑세스하는 정도도 다름
1. 로그인 비밀번호 암호화
사람들은 보통 여러 사이트에서 동일한 이메일과 비밀번호를 사용하는 경우가 많은데 특정 사이트에서 DB가 해킹 당한다면 다른 서비스까지 추가 해킹을 당하는 일이 발생할 수 있게 된다. 따라서 기밀성을 위해 비밀번호를 암호화하여 저장함.
구성 요소
- 평문(Plaintext) : 해독 가능한 형태의 메시지(암호화전 메시지)
- 암호문(Cipertext) : 해독 불가능한 형태의 메시지(암호화된 메시지)
- 암호화(Encryption) : 평문을 암호문으로 변환하는 과정
- 복호화(Decryption) : 암호문을 평문으로 변환하는 과정
암호화의 2가지 종류
- 양방향 암호화 : 암호화와 복호화과정을 통해 송 ・ 수신 간 주고받는 메시지를 안전하게 암호화하고 평문으로 복호화하는 과정.
- 단방향 암호화 : 해싱(Hashing)을 이용한 암호화 방식으로 양방향과는 다른 개념으로, 평문을 암호문으로 암호화는 가능하지만 암호문을 평문으로 복호화 하는 것은 불가능.
2. 로그인
서버 기반 인증 시스템
서버 기반 인증 시스템은 서버측에서 유저들의 정보를 기억하고 있어야 해서 여러가지 문제점이 발생
- 서버가 유저의 인증 기록을 세션에 저장하는데, 로그인 유저가 많아지면 서버가 과부하에 걸림
- 세션을 사용하면 분산된 시스템을 설계하고 서버를 확장하는 것이 힘듦
- 세션을 관리할 때 사용되는 쿠키는 여러 도메인에서 관리하는 것이 번거롭다.
그렇기에 토큰 기반 인증 시스템을 사용하기 시작
토큰 기반 인증 시스템
Stateful Server의 경우 클라이언트에게 요청을 받을 때마다 상태를 유지하고 정보가 서비스 제공에 이용.
Stateless Server에서는 상태정보를 저장하지 않고, 서버는 세션을 이용하지 않고 클라이언트의 요청만으로 작업을 처리. 따라서 토큰을 사용하면 클라이언트와 서버의 연결고리가 없어 서버를 확장하기에 매우 적합한 환경을 제공. 서버를 확장시키는 것 뿐 아니라 로그인 정보가 사용되는 분야를 확장
3. 로그인 프로세스
- 사용자가 로그인
- 서버에서 사용자가 입력한 ID, PW를 회원 DB에서 값을 비교
- 로그인이 완료되면 accessToken(JWT), refreshToken(JWT) 을 발급
- accessToken : 해당 데이터 payload를 통해 전달
- refreshToken : 쿠키를 통해 전달
- 잘 이용하다가 시간이 지나면 만료된 accessToken을 첨부하여 요청
- 서버가 인가를 해보면서 토큰이 만료되었음을 확인하고 에러를 반환
- accessToken 만료가 되어 인가시 에러가 반환되면 refreshToken으로 accessToken을 재발급 받는 API를 프론트에서 요청
- 토큰이 만료되었음을 확인하고 토큰 재발급 요청을 restoreAccessToken 쿠키와 함께 요청
- 쿠키에 refreshToken을 확인해(인가) 새로운 accessToken을 발급해서 반환
- 정상적으로 요청에 대한 값을 반환
4. 소셜 로그인 프로세스
- 프론트엔드에서 만들어진 소셜로그인 버튼을 클릭하면 social login API가 실행
- 인가를 받기 위해 AuthGuard가 프론트엔드 페이지(브라우저)를 해당 소셜 로그인 페이지로 이동
- 로그인을 진행
- 로그인 정보가 해당 소셜 서버로 넘어가 인가를 진행
- 인가가 정상적으로 이루어지면 서버에서 해당 소셜로그인 페이지로 응답
- 받은 응답을 가지고 이용하려는 서비스의 로그인 API를 다시 진행합니다.
- 해당 소셜에서 가저온 정보로 DB에 저장
- 서비스 이용
풀리면 재밌는 알고리즘