본론
중간에 알고리즘 하나 풀어서 딴길로 잠깐 샜는데 아래가 오늘 공부한것
벨로그 들어오는길에
코딩 컨벤션이라는글을 봤는데
요는 읽고, 관리하기 쉬운 코드를 작성하기 위한 일종의 코딩 스타일 규약 이라것이고
코딩 컨벤션의 장점
• 정해진 규칙이 있기 때문에 명칭이나 구조를 빠르고 정확하게 정할 수 있음.
• 통일된 규약으로 인해 코드를 이해하기 쉬고 편리하게 사용 가능.
• 유지보수 비용 절약.
이있다 커밋하고 깃을 쓸때마다 컨벤션을 해줘야하는데 자동으로 해주는 라이브러리가 있다고 해서 남겨놓은다
요기
모달창
내 처음 미니프로젝트에서 모달창을 이용해서 각 카드의 내용을 모달창안으로 가져오는 기능이였는데 딱 하나의 모달창을 이용하여 구현을 했다.
이와 다르게 모달창 여러개를 이용하는 방법을 아래 링크가서 볼수 있다
herf="https://m.blog.naver.com/is_king/221558556475"
JWT, API
일단 JWT는 JSON Web Token의 약자이고 인증에 필요한 정보들을 암호화시킨 토큰이다
JWT 기반 인증은 쿠키/세션 방식과 유사하게 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라를 식별한다.
JWT의 구조
는 위 사진과 같이 세가지 문자열의 조합이다. 실제 디코딩된 JWT는 Header, Payload, Signature로 이루어져 있다.
Header는 alg와 typ을 갖고 있다.
alg는 정보를 암호화할 해싱 알고리즘을, typ는 토큰의 타입을 지정한다.
{
"alg": "HS256",
"typ": "JWT"
}
Payload
Payload는 실제로 토큰에 담을 정보를 지니고 있다.
주로 클라이언트 고유 ID, 유효 기간 등이 포함된다.
Key-Value 형식으로 이루어진 한 쌍의 정보를 Claim이라고 한다.
{
'id': id_receive,
'exp': datetime.datetime.utcnow() + datetime.timedelta(minutes=30),
}
Signature
Signature는 인코딩된 Header와 Payload를 더한 뒤, 비밀키로 해싱하여 생성한다.
Header 및 Payload는 단순 인코딩된 값이기 때문에 해커가 복호화하고 조작할 수 있지만, Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다.
따라서 Signature는 토큰의 위변조 여부를 확인하는 데 사용된다.
token = jwt.encode(payload, SECRET_KEY, algorithm='HS256')
payload = jwt.decode(token_receive, SECRET_KEY, algorithms=['HS256'])
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret_key
)
토큰 인증 과정
클라이언트 로그인 요청이 들어오면, 서버는 검증 후 클라이언트 고유 ID등의 정보를 Payload에 담는다.
암호화할 비밀키를 사용해 Access Token(JWT)을 발급한다.
클라이언트는 전달받은 토큰을 저장해두고, 서버에 요청할 때마다 토큰을 요청 헤더 Authorization에 포함시켜 함께 전달한다.
서버는 토큰의 Signature 을 비밀키로 복호화한 다음, 위변조 여부 및 유효 기간 등을 확인한다.
유효한 토큰이라면 요청에 응답한다.
토큰의 장점
Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.
인증 정보에 대한 별도의 저장소가 필요 없다. (I/O 처리 필요 없음)
JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됐음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.
클라이언트의 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(Stateless)가 된다.
확장성이 우수하다.
토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. (토큰 서버 활용)
OAuth의 경우 Facebook, Google 등 소셜 계정을 이용해 다른 웹서비스에서도 로그인 할 수 있다.
모바일 어플리케이션 환경에서도 잘 동작한다.
https://mangkyu.tistory.com/55 도 참고하면 좋다
토큰의 단점
쿠키, 세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많을수록 네트워크 부하가 심해진다.
Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다. (패스워드 등)
토큰을 탈취당하면 대처하기 어렵다. 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하다.
특정 사용자의 접속을 강제로 만료하기 어렵다. (쿠키/세션 기반 인증은 서버 단에서 쉽게 삭제할 수 있지만 토큰은 그게 안 됨)
이러한 단점을 보완하기 위한 토큰 전략들은 몇가지가 있다.
아래에서 살펴보자.
짧은 만료 기한 설정
토큰의 만료 기한을 짧게 설정해서 탈취되더라도 빠르게 만료시키는 방법이다.
하지만 이는 토큰이 만료되면 사용자가 다시 로그인해야 한다는 뜻이기에 사용자 입장에서 번거로운 방법이다.
Sliding Session
서비스를 지속적으로 이용하는 클라이언트에게 자동으로 토큰 만료 기한을 늘려주는 방법이다
만약 글을 작성하다가 토큰이 만료된다면 새로운 토큰을 발급해주는 것이다.
사용자가 로그인을 자주 할 필요가 없다.
Refresh Token
클라이언트가 로그인할 때 Access Token 및 Refresh Token을 발급해주는 방법이다.
Refresh Token은 Access Token보다 만료 기한이 긴 토큰이다.
클라이언트가 요청을 보냈는데 Access Token이 만료되었을 때, Refresh Token을 이용하여 Access Token의 재발급을 요청한다.
이때 서버는 DB에 저장된 Refresh Token과 비교하여 유효하면 Access Token을 발급한다.
만약 Refresh Token도 만료된 경우라면 사용자에게 로그인을 요구한다.
이 전략을 사용하면 Access Token의 만료 기한을 짧게 설정하여 위의 짧은 만료 기한 설정 전략처럼 탈취되더라도 빠르게 만료될 수 있다. 또한 짧은 만료 기한에도 불구하고 자주 로그인을 할 필요가 없어진다. 서버가 강제로 Refresh Token을 만료시킬 수도 있다.
하지만 이렇게 완벽하게 보이는 Refresh Token 발급 방법도 단점은 있다. Refresh Token 검증을 위해 DB(혹은 별도의 저장소)에 저장해야 하고, 자원이 소요될 뿐더러 추가적인 I/O 작업이 발생한다. (JWT의 장점은 I/O 작업이 필요없는 빠른 인증 처리였다.)
쿠키와 세션
간단하게 쿠키는 클라이언트의 브라우저에 설치되는 작은 기록파일
세션은 이걸 서버측에서 저장하고 관리하는것
두개의 비교는 이 블로그에서 보자
API
Application Programming Interface
나는 처음에 api가 open api만 api인줄 알았다
보통 api를 은행 창구에 비교를 해서 설명을 해줬는데
맞는말인거 같다
브라우저에서 어떤 데이터를 가지고 오고싶으면 api를 통해 요청이 가고 서버에서 데이터를 보내주니까 중간다리 역활,즉 프로그램에서 데이터를 전달해주는 방법이겠다
API의 유형
API가 제공하는 데이터에 대한 접근성에 따라, 총 3가지 유형으로 나눌 수 있다.
1. private API
내부 API로, 회사 개발자가 자체 제품과 서비스를 개선하기 위해 내부적으로 발행하므로 제 3자에게는 노출되지 않는 API이다.
2. public API
개방형 API로, 모두에게 공개된다. 누구나 제한 없이 사용할 수 있다.
3. partner API
데이터 공유에 동의하는 특정인들만 사용할 수 있다. 파트너 회사 간에 소프트웨어를 통합하기 위해 종종 사용된다.
