9주차 스터디 유저 기능 원리 [코드잇 부스트 백엔드 스터디 ]

1. 인증과 인가

 

유저 기능이란?

 
 

 
 
리퀘스트를 보낸 사용자가 누구인지를 파악하는 인증
리퀘스트마다 할 수 있는 걸 제한하는 인가
→ 유저기능
 
 
 

인증(Authentication)

 
유저기능의 기본
🔹인증을 하기 위해선 서버에 유저에 대한 정보가 저장되어 있어야함
🔹유저를 나타내는 모델이라는 걸 만든다
 
모델이란?
🔹 클래스랑 비슷하게 특정 리소스에 대한 정보를 관리하기 편하게
코드로 표현해놓은것

 
인증
🔹 유저별로 각각 다 다른 인증서를 가지고 있기 때문에 모두 구별 지을 수 있다
🔹인증서는 보통 만료 기간이 있다
→ 특정 시간이 지나면 무효화돼서 더 이상 사용할 수 없게 된다 (로그아웃)
 
 
 
 

쿠키 인증

 
 
쿠키
🔹서버 리스폰스나, 클라이언트 코드에 따라 브라우저에 저장되는 작은 단위의 문자열 파일
 

🔹속성엔 서버에서 정한 만료일이나 보안 설정 등 다양한 내용들이 있다
 
 
💡서버는 인증서를 리스폰스의 Set-Cookie 헤더를 통해서 클라이언트에 저장할 쿠키로 전달한다
🔹리스폰스를 받은 클라이언트 브라우저는 쿠키 이름과 값을 저장하고 Set-Cookie에 나와있는 다양한 설정들을 적용한다
 
 
쿠키 저장과 전송
브라우저에서 자동으로 해준다 → 조금 더 편리하게 인증 구현 가능
 
 
 

쿠키 보안

 
쿠키는 유저 인증뿐만 아니라, 브라우저 이용자에 대한 개인화된 기능과 데이터 제공 수단으로 사용할 수있다.
 
Secure
서버에서 리스폰스를 보낼 때 이 설정을 추가해 주면 HTTP보다 보안에 강한 HTTPS를 사용할 때만 클라이언트에서 서버로 쿠키가 보내진다

Set-Cookie: cookie_name=cookie_value; Secure;

 
HttpOnly
이 설정을 추가하면 클라이언트가 자바스크립트 코드로 해당 쿠키에 접근할 수 없게 된다

Set-Cookie: cookie_name=cookie_value; Secure; HttpOnly;

 
SameSite
세 번째는 SameSite입니다. 이 설정은 Cross site request forgery의 약자, CSRF(또는 XSRF)라는 공격을 예방할 수 있는 설정

Set-Cookie: cookie_name=cookie_value; Secure; HttpOnly; SameSite=Lax;

 
 
 

Authorization 헤더 인증

 
 
클라이언트가 인증서를 직접 저장하고 리퀘스트의 Authorization 헤더를 통해 서버에 보내는 방법
쿠키는 클라이언트의 자바스크립트 코드로도 저장 및 접근 가능하다
 

 
 

세션 기반 인증

 
인증서는 크게 두가지로 나눠진다
작동하는 원리에 따라 세션과 토큰으로 나뉜다
 

 
세션
🔹서버가 저장하는 사이트 방문자들에 대한 기록

 
 
 
평생 같은 세션 아이디를 사용할 수 있는 건 아니다
→ 특정 시간이 지나거나 유저가 로그아웃 리퀘스트를 보내면 서버는 해당 세션이나 로그인 유저를 만료쳐리한다!
 
 
 

토큰 기반 인증

 
인증 토큰
🔹유저에 대한 정보를 암호화한 문자열
 
서버만 알고있는 문자열인 비밀키를 사용해서 암호화한다
 

 
 

인코딩과 Base64URL

 
 
인코딩
🔹데이터를 여러 곳에서 쉽고 안정적이게 사용하기 위해 통일된 형식으로 바꾸는 걸 ‘인코딩’이라고 부른다
 
 
Base64 인코딩
🔹Base64는 데이터를 0과 1로 표현하고 이걸 6자리씩 끊어서 ASCII에 포함된 64 문자 중 하나로 바꿔주는 인코딩 방식
 
 
 

기본 인증

 
 
사실 인증을 할 때는 “인증서”의 개념을 아예 사용하지 않아도 된다그냥 온전히 이메일과 비밀번호만 사용할 수도 있다
 
기본 인증
🔹리퀘스트의 Authorization 헤더를 사용
 
🔹 큰 인증을 할 때 Authorization 헤더 뒤에 Bearer 또는 Token 그리고 뒤에 토큰을 붙였던 것과 비슷하게 Authorization 헤더 뒤에 Basic, 그리고 이메일과 비밀번호를 :로 이어서 붙여주면 된다
 
 
 
기본 인증 단점
🔹 모든 리퀘스트에 이런 민감한 데이터를 보내면 악의를 갖는 공격자가 중간에서 가로챌 위험이 커진다
 
 
 
 

JWT

 
JWT
🔹가장 널리 사용되는 토큰 형식 중 하나
🔹json 형식의 데이터를 문자열로 인코딩한 토큰

 
 
🔹exp: 만료시간( expiration time)
🔹iat: 발급시간(issued at)
🔹jti: 토큰 고유값 (JWT ID)
🔹uesr_id: 토큰이 인증하려는 유저
 
페이로드 부분에는 공식적으로 사용되는 필드 이름들이 몇 개 있다
→ 여러 서비스들 사이에서 jwt 토근을 사용할 때 같은 내용이 서로 다른 필드의 이름으로 있으면 문제가 발생할 수 있어서
 
 

 
따라서 민감한 정보는 Header와 Payload 부분에 넣지 않는다
 
💡시크릿 키를 알지 못하는 클라이언트가 토큰 내용을 수정하면 시그니처 부분이 바뀌기 때문에 서버가 해당 토큰의 유효성을 인정하지 않는다
 
 
 

인가(Authorizaion)

 
 
인증 후 인가가 보통 플로우
 
 
 
 

---

 

2. 위임 

접근 권한 위임과 OAuth

 
 
여러서비스 사이에서 유저기능을 사용하는 것
 
접근 권한 위임
🔹한 서비스가 다른 서비스에 있는 보호된 리소스에 대한 접근 권한을 위임하거나 받는 기능
 
OAuth
🔹개방형 접근 권한 위임 표준
🔹리퀘스트의 접근 권한을 확인하기 위한 인가를 위한 표준
 
 
 
 

OAuth 주체와 설정

 
 

 
 
1. 구글 인가서버에서 client ID와 Secret을 받는다

 
2.리퀘스트가 코드잇에서 온다는 걸 증명하기 위해서 필요한 값들
→ 미리 백엔드 서버에 저장해놓는다
 
 
3. Scope를 정한다
 
 

 
 
 
 
코드잇이 유저로부터 넘겨받는 권한의 범위
인가 서버를 설정할 때 Scope를 정의해놓으면, 유저는 딱 해당 범위 안의 권한만 위임할 수 있다
 
 
 
 

OAuth 워크플로우

 

 
Authorizaiton code
유저 본인이 권한 위임을 원한다는 걸 확인 시켜주는 데이터
 

 
 
 

OpenID Connect

 
 
여러 서비스들 사이에서 인증도 같이 할 때 OIDC를 사용한다
→ OIDC는 OAuth에 인증까지 포함시킨 표준
 
OpenID Connect는 하나의 계정을 사용해서 여러 사이트들에서 인증을 받을 수 있게 하기 위해서 만들어진 표준
 

 
OpenID Connect도 OAuth와 마찬가지로 서비스를 사용하기 전에 먼저 OpenID 프로바이더에서 설정을 해줘야한다