user의 id와 password를 확인하는 절차
user에 대한 권한을 확인하는 것
👉 한 번 인증을 받은 사용자가 이후 여러 기능들을 사용할 때 내 계정으로'만' 할 수 있는 활동들을 시도할 때 내가 로그인이 되어있음을 알아보고 허가를 해주는 것!
즉 인증 이 이루어진 후에야 인가가 이루어짐을 알 수 있다.
👉 자원을 적절한/유효한 사용자에게 전달/공개하기 위한 방법이 "인증과 인가"인 것이다.
인증을 하는 방법에는 크게 4가지가 있다.
Request Header, Browser, Session, Token을 활용해서 가능하다.
각각의 방식을 살펴보자---!
🔖 HTTP의 기본 성질 : stateless(무상태성)
Request Header만 사용할 시, 사용자가 매번 로그인을 해줘야한다는 문제가 생긴다. (매번 인증을 해야함)
Browser에 있는 storage의 힘을 빌린다. ex) local storage, session storage, cookie
ex)
쿠키에 사용자 아이디와 비밀번호를 집어 넣는다. 사용자가 인증이 필요한 요청을 할 때 해당 정보를 같이 넣어서 보내준다. 👉 DB 체킹이 되어 원하는 자원을 받을 수 있음!
But, 사용자의 정보가 그대로 노출이 되어있어 위험도가 높다. 보안 취약.
그렇다면 Server에 도움을 요청해보자.
Server중에서도 Session을 활용해보자-!
🔖Session ? 인증된 사용자의 식별자와 랜덤한 문자열로 세션 ID를 만들어서 이를 응답헤더에 넘겨주고 클라이언트가 저장을 할 수 있도록 만드는 것.
👉장점? 위험도 낮아진다. 세션의 만료기간을 정할 수 있다. 만료기간이 지날경우 해커가 가져갈 경우에는 정보가 유효하지 않다!
👉문제점? 만약 여러 개의 server가 존재할 경우, 한번 세션을 통해서 인증을 받으면 그 다음부터 세션으로만 요청을 하게 된다. 이 상황에서 유저가 두번째 인증에 대한 요청을 다른 server에 하게 되면 기존의 server가 갖고있던 session 아이디를 갖고 있지 않기 때문에 오류 발생-! (서버 하나하나 자체에서 세션을 관리하고 있어서 생긴 문제)
위의 문제를 해결하기 위해 Session storage에서 한꺼번에 session 관리할 수 도 있다.
But session storage 또한 client의 요청이 너무 많아지면, 오류 발생가능성 ⭕️
Token : 사용자와 서버 간의 data 요청과 응답 안에 사용자의 상태를 담아 사용자의 인증과 인가를 처리하는 것
그 Token의 유명한 방식이 JWT(Json Web Token)
JWT ? 간단히 설명하면 시크릿 키를 사용해서 JWT를 만들어낸다. 시크릿 키를 사용해서 JWT의 인증과정을 거친다. JWT 자체에는 민감한 정보(ex 비밀번호)를 담지 않음. 시크릿 키를 서버 내부에 잘 관리하는 방식 - !
👉간단한 방식)
클라이언트 ----> 서버로 토큰이 넘어감. 서버는 토큰의 유효성 검사를 본인이 가진 시크릿키로 진행을 한다. 유효하다면 그 때 사용자 정보, 만료시기, 권한 등 확인
👉장점? 여러 대의 서버에서도 같은 방식으로 진행 가능
👉문제점? access token 탈취 당하면 해커가 사용자 입장 => 이를 보완하고자 짧은 만료시간(2시간 정도)
++ Refresh 토큰
access token의 짧은 만료시간이란 점을 보완하기 위해 refresh 토큰이 등장한다.
🔖 refresh 토큰? access token을 재발급받을 수 있는 token이다
이 token은 서버에 저장되기 때문에(stateful) refresh token이 해커에 의해 탈취당했다고 판단되었을 때 서버에서 refresh token을 삭제함으로써 강제 로그아웃을 시킬 수 있다.
어렵다.. 어려워,,,, 인증 인가 실습하면서 좀 더 배운 개념들을 실전에 적용해봐야겠다,,,!