Authentication
- 리퀘스트를 보낸 유저가 누구인지 파악하는 기능
- 서버에 유저에 대한 정보가 있어야함
- 유저를 나타내는 모델(유저 클래스)을 만들어야 함 (특정 지을수 있는 유일한 id나 email, 암호화한 pw)
● 회원가입
- 서버에 유저 정보를 저장하는 행위
workflow
1. 회원 가입 페이지에서 이메일, 필수정보 등을 입력.
2. 입력한정보를 리퀘스트 body에 담은 후, 회원가입을 담당하는 서버 URL로 POST.
3. 서버에서는 인증정보에대해서 간단한 테스트(중복확인) 후, 유저를 특정할 수 있는 자연수 id 값과 함께 저장.
4. 통과하면 200 OK, 통과하지 못하면 400 Bad Request.
● 로그인
- 서버의 유저 정보를 특정하는 행위
workflow
1. 로그인 페이지에서 이메일, 필수정보 등을 입력.
2. 입력한 정보를 리퀘스트 body에 담은 후, 로그인을 담당하는 서버 URL로 POST.
3. 서버에서는 어떤 유저가 인증을 원하는지 특정, 비밀번호로 그 계정의 주인인지를 확인.
4. 통과하면 문자열 형식의 (인증서 | 증명서) 와 함께 200 OK, 통과하지 못하면 400 Bad Request.
5. 로그인 성공 시, 인증서를 클라이언트에 저장 후, 이후 리퀘스트를 보낼 때 인증서를 붙혀서 같이 보내줌.
● 클라이언트가 서버에 인증서를 받고 저장한 후, 다시 서버에게 전달하는 방법 2가지.
1. 쿠키 인증.
쿠키 : 서버 리스폰스나 클라이언트 코드에따라 브라우저에 저장되는 작은 단위의 문자열 파일들.
<cretidicate=1a2b3c; expires=Wed, 20 Apr 2022 06:17:36 GMT; SameSite=Lax; Secure>
- cretidicate: 이름
- 1a2b3c: 값
- expires=Wed, 20 Apr 2022 06:17:36 GMT, SameSite=Lax, Secure : 속성
- SameSite 속성 : CSRF공격을 예방할 수 있다.
- Secure 속성을 추가하면 HTTPS를 사용할 때만 클라이언트에서 서버로 쿠키가 보내진다.(HTTPS는 항상 리퀘스트와 리스폰스가 암호화되기 때문에 누군가 중간에 리퀘스트를 가로챘을 떄 정보 유출을 줄일 수 있다.)
● 서버 리스폰스로 저장하는 방법.
1. 서버가 로그인 리퀘스트를 확인 후, 인증서를 만들고, 리스폰스 객체의 set-Cookie 헤더를 통해 클라이언트에 저장할 쿠키 전달한다.
2. 리스폰스를 받은 클라이언트 브라우저는 쿠키 이름과 값을 저장하고 다양한 설정들을 적용한다.
3. 이후 브라우저가 리퀘스트를 보낼때 자동으로 Cookie라는 헤더에 추가돼서 보내진다. 그리고 서버는 리퀘스트 객체의 쿠키 헤더를 확인하고, 이 인증서를 통해서 어떤 유저인지 특정한다.
4. 브라우저에 저장된 모든 쿠키가 모든 리퀘스트에 보내지는 건 아니고 쿠키를 설정한 웹사이트에만 보내진다.
예를 들어 페이스북이 브라우저에 쿠키를 저장할때, 브라우저에서 페이스북으로 보내는 리퀘스트에는 쿠키가 포함되지만 구글로 보내는 리퀘스트에는 쿠키가 포함되지 않는다. 하지만 같은 루트 도메인을 공유하는 사이트와는 공유할 수 있다.
2. Authorization 헤더
1. 서버가 리스폰스 객체의 set-Cookie 헤더에 인증서를 추가하지 않고 body에 인증서를 추가하고 클라이언트에 보낸다.
2. set-Cookie가 없으니 브라우저가 자동으로 저장하지 않는다. 대신 개발자가 작성한 코드로 이 인증서를 직접 저장함.
3. 서버에는 로컬스트리지라는 공간도 있는데 이걸 자바스크립트 코드로 접근할 수 있다.
● 저장한 인증서를 Authoiazation 헤더를 통해서 서버에 전송하는 방법.
- 리퀘스트 객체에 Authorization 헤더를 추가하고 그 뒤에 인증서를 붙혀준다.(브라우저가 자동으로 해주지 않는다.)
- 리퀘스트를 받은 서버는 Authorization 뒤에 있는 인증서를 통해서 유저를 특정한다.
Authorization 헤더 인증의 장점
- 리퀘스트에 인증서를 붙일지 안 붙일지 선택 가능.
- 서로 다른 루트 도메인 사이 인증 가능.
인증서는 작동하는 원리에따라 세션과 토큰으로 나뉜다.
- 세션 : 세션 기반 인증
- 토큰 : 토큰 기반 인증
1. 세션 기반 인증
- 세션이란 서버가 저장하는 사이트 방문자들에 대한 기록.
- 사용자가 서버에 첫 리퀘스트를 보내면 서버는 이 방문에 대한 데이터 저장한다. (방문을 특정 지을 수 있는 id값, ip주소, 마지막 방문, 사용 브라우저 등)
- 리스폰스 객체의 Set-Cookie 헤더에 새롭게 만든 세션을 추가한다.
- 이후, 클라이언트가 쿠키를 포함한 리퀘스트를 보내면 브라우저에서 자동으로 설정해주는 쿠키를 통해 유저를 특정할 수 있음.
2. 토큰 기반 인증
- 유저에 대한 정보를 암호화한 문자열인 인증 토큰을 통해서 리퀘스트를 보낸 유저를 파악.
- 서버에 보내서 유저가 특정 기능이나 콘텐츠에 접근할 수 있게 해주기 때문에 엑세스 토큰이라고도 부른다.
- 서버는 세션과 같이 유저의 로그인 상태를 저장힌 후 리퀘스트를 저장,. 확인하지 않고 유저를 특정할 수 있음.(토큰 자체를 해석)
workflow
- 서버가 사용자 특정에 성공할 경우 토큰(주로 JWT)을 생성하고 비밀키로 암호화 한다.
- 생성한 토큰을 클라이언트에 전송할 때 set Cookie를 통해서 쿠키인증을 사용할수 있지만 리스폰스 바디에 토큰을 저장해서 전송하는 것이 조금 더 일반적.
- 토큰을 돌려받을 때도 쿠키보다 Authoriaztion 헤더를 통해 돌려받는 것이 더 일반적
(Authorization: Bearer (토큰으로 암호화된 문자열))
- 로그아웃을 위해선 클라이어언트에 직접 토큰을 삭제.
'User function' 카테고리의 다른 글
| JWT(JSON Web Token) (0) | 2024.02.02 |
|---|
