👉 Authentication
일단 Authentication(인증)과 Authorization(인가/허가)은 서로 다르다.
- Authentication(인증) : 본인이 맞는가에 대한 확인
- Authorization(인가/허가) : 권한이 존재하는가에 대한 확인
✏️ stateful
session이 있다는 것이 바로 state가 존재한다는 것이기에, stateful한 인증 방식에는 전통적으로 사용하는 인증 방식인 session을 이용한 인증이 해당된다.
HTTP 프로토콜은 stateless하기 때문에 cookie와 session을 사용하여 stateful한 인증을 지원한다.
cookie는 web에서의 정보를 저장하는데, 서버에 요청을 보낼 때마다 헤더에 로컬 cookie를 담아 전송한다.
서버와의 통신 시 항상 주고 받아지는 정보이기 때문에 보안이 취약하고 크기가 작아 중요한 정보를 담기에는 좋지 않기 때문에 session을 같이 활용한다.
session은 session id와 서버에 해당하는 값으로 구성되어 있으며, secret key로 암호화되어 전달이 된다.
사용자가 서버에 요청을 보내게 되면 서버는 session을 생성하여 저장소에 저장을 하고 해당하는 session id를 사용자에게 보내준다.
이후 요청 마다 사용자는 받은 session id를 cookie에 담아 전송하게 되고, 서버는 cookie에 담긴 session id를 key로 저장소에서 해당하는 정보를 찾아 인증을 수행한다.
서버에서 session을 다루는 방법은 두가지로 볼 수 있는데,
- session에 대한 정보를 서버에 저장
-> server에 정보를 저장하기 때문에 사용자의 수가 늘어나게 된다면 서버의 부담이 늘어나게 된다. - session data를 cookie로 전부 암호화해서 사용
-> server에 별도의 저장 공간을 필요로 하지 않으나 보안상 취약할 수 있다.
✏️ stateless
Token 방식을 이용한 인증 방법이 stateless 인증 방식에 해당한다.
Token을 이용하여 인증을 진행하면 서버가 전달받은 token만을 검사하면 되기 때문에 서버에 별도의 저장소를 필요로하지 않으며, 서버 부담을 줄일 수 있다.
다만 부여된 token은 유효 기간이 만료되기 전 강제로 만료시킬 수 없어 부여된 권한이 token 만료까지는 무조건적으로 유지된다.
👉 JWT
JWT는 JSON Web Token을 의미하며, token의 한 종류로 좋은 token을 위한 format을 제공한다.
JWT는 .으로 구분된 3개의 덩어리로 구분된다.
- encode된 방식
- data
- 검증 코드
Token은 base64로 encoding 되어 있으며, JWT 사이트에서 그 값을 decoding 해볼 수 있다.
JWT는 token을 이용하여 인증을 하므로 token이 만료될 때까지 권한이 유지된다는 것이 단점이다.
👉 OAuth 2.0
OAuth 2.0은 외부 서비스(3rd party)의 안전한 인증을 위한 방식을 정해놓은 framework이다.
OAuth 2.0을 기반으로 하는 서비스의 API를 호출할 때에는 HTTP header에 ACCESS_TOKEN을 담아 요청을 보낸다.
👉 구성 요소
- OAuth server
- client : client id + client secret
- redirect uri (각 client 마다) : redirect uri가 맞는 경우에만 값을 전송
- scope : 쓸 수 있는 권한에 대한 정보
👉 인증 흐름
✏️ password grant
username과 password 만을 이용해 인증을 진행하는 방식이다.
사용자가 usename과 password로 로그인을 시도한다.
권한이 있는 사용자인 경우 OAuthServer는 ACCESS_TOKEN을 내려준다.
✏️ authorization code grant
사용자가 1st party(OAuth Server)에서 login이 완료되면 3rd party에서 authorization code만을 보내준다.
3rd party에서 로그인을 할 때에는 사용자를 1st party 인증 페이지로 보내서 authorization code를 받고 authorization code를 ACCESS_TOKEN으로 교환한다.
password grant와는 다르게 서버와 서버가 통신하는 과정이 존재한다.
✏️ refresh token grant
ACCESS_TOKEN의 재발급을 위해서 사용하는 token이REFESH_TOKEN이다.
REFESH_TOKEN을 이용하여 사용자는 새로운 ACCESS_TOKEN을 재발급 받을 수 있다.
ACCESS_TOKEN의 만료를 확인하기 위해서는
ACCESS_TOKEN의 유효기간을 같이 저장하여 유효기간 확인을 통해 만료 확인- 존재하는
ACCESS_TOKEN을 이용한 요청을 보내서 reject되면 유효기간이 만료되었다고 판단
하는 방식이 존재한다.
✏️ implicit grant
authorization code grant 방식을 간소화한 방식이다.
원본 서비스(1st party)의 인증 페이지로 사용자를 보내서 ACCESS_TOKEN을 authorization code 없이 바로 발급 받도록한다.
BE server가 없는 경우에 사용하는 방식으로 많이 사용하는 방식은 아니며, 권한이 작고 token의 유효기간이 짧다.
OAuth 2.0이나 JWT 둘 중 하나만 사용하는 것이 아니라 처리 방식은 OAuth 2.0을 쓰면서 token은 JWT를 쓰는 등의 방식으로 인증을 할 수 있다.
