인증과 인가
인증과 인가란 무엇인가?
인증이란 사용자가 누구인지를 판단하는 것을 의미하며,
인가는 인증이된 사람에 대한 권한을 의미한다.
인가는 인증이 선행되어지고 난 뒤에 행해지는 것이다.
우리가 위코드에 들어오기 위해서는 카드키가 필요하다.
여기서 카드키는 인증에 해당한다.
카드키 를 이용해서 들어오는 사람이 인증된 사람인지 아닌지를 판단할 수 있다.
하지만 우리는 이 카드로 엘리베이터를 이용해서 8층과 10층 이외의 다른 층에는 갈 수 없다. 그 이유는 권한이 없기 때문이다. 이때 이 권한이 인가이다.
우리는 카드를 통해 인증을 했고, 8층과 10층은 갈 수 있는 권한이 있어 인가는 되었지만, 다른 층에 대해서는 권한이 없어 인가가 되지 않았다.
이렇듯 인증과 인가는 실생활에서도 사용되는 개념이다.
인증 : 식별가능한 정보로 서비스에 등록된 유저의 신원을 확인하는 과정
인가 : 인증된 사용자에 대한 자원 접근 권한 확인
자원을 적절한/유효한 사용자에게 전달/공개 하기 위한 방법이다.
참고: https://www.youtube.com/watch?v=y0xMXlOAfss
우리는 웹상에서 클라이언트와 다양한 통신을 할 것이다. 이때 인증과 인가가 없으면, 누구나 데이터에 접근할 것이고, 정보 중에는 개인정보등의 중요한 정보가 포함되어 있을 수 도 있다.
그렇기 때문에 반드시 인증과 인가를 통해서 누가 사용하는지, 그리고 사용한다면, 사용하는 사람에 대한 권한은 어떤지를 생각해야 할 것이다.
인증
웹상에서 가장 대중적으로 사용되는 인증은 로그인일 것이다. 웹페이지에서 로그인을 통해 사용자가 누구인지를 알수 있다.
유저의 identification을 확인하는 절차로 위에서 말한 것과 같이 아이디와 비밀번호를 확인하는 단계이다.
인가
로그인이라는 인증을 통해서 로그인에 성공했다. 이제 내 정보에 접근해보도록 하자.
또 다시 로그인을 요구할 것이다.
왜일까?
이미 한번 로그인을 해서 인증이 완료 되었는데, 왜 다시 인증을 요구하는 것일까?
이는 통신의 stateless속성 때문에 발생하는 문제이다.
통신은 이전 작업과 후속 작업에 연관성이 없다고 생각한다. 그렇기 때문에 현재
로그인을 해서 인증이 되었다고 해도, 다음 통신에서는 로그인을 되었다고 생각하지 않는다.
그렇다면 우리는 계속해서 로그인을 해주어야 할까?
이에 대한 해답이 쿠키, 세션, 토큰 등이 있다.
1. 쿠키-세션
2. 토큰-세션
3. 토큰-jwt
쿠키
클라이언트가 특정 웹사이트에 접속한다는 것은 특정 웹사이트의 서버에 요청을 한다는 것이다.
이때 서버는 클라이언트에 응답과 함께 쿠키도 넘겨주게 된다. 쿠키에는 클라이언트의 인증을 위한 정보를 넣을 수도 있다.
이렇게 넘어온 쿠키는 브라우저에 저장되게 된다.
그리고 동일 웹페이지에 접근할 때마다, 브라우저에서는 자동적으로 쿠키를 서버에 보내주게 된다.
쿠키에는 유효기간이 있고, 웹사이트마다 쿠키는 다르다.
하지만 쿠키에 인증을 위한 정보를 담아서 보낼 경우, 쿠키는 클라이언트쪽에 있으므로 해커로 부터 탈취당하기 쉽다.
세션 vs 토큰 vs JWT
세션
쿠키가 인증으로서 보안상의 단점이 있다는 점을 알았다. 그래서 정보를 서버쪽에 저장하는 것이 세션이다.
세션을 이해하기 전에 알아야하는 것은 http프로토콜의 속성인 statless이다.
stateless는 서버에 가는 모든 요청이 이전 요청과 이후 요청이 모두 연관관계가 없다고 생각하는 것이다. 그렇기 때문에 현재 로그인을 한단고 해도, 다음 요청시에는 서버는 내가 누구인지 모르게 된다.
그렇다면 요청할 때마다 내가 누구인지 알려주어야 할까?
이 문제를 해결 하기 위한 방법이 세션이다.
세션의 동작원리
- kim유저가 로그인을 하기 위해 이메일과 비밀번호를 서버에 보낸다.
- 비밀번호가 맞으면 서버에서 세션DB에 kim유저를 생성한다.
- 세션DB에 별도의 ID가 생성되는 것이다.
- 세션ID는 쿠키를 통해서 브라우저에 돌아오고, 브라우저에 저장된다.
- 동일 웹사이트에서 다른페이지로 이동할 때마다, 브라우저는 세션ID를 가진 쿠키를 서버에 자동으로 보내준다.
- 서버는 들어오는 쿠키를 보고, 그 중 세션ID가 함께 오는 쿠키를 확인한다.
- 지금 단계에서는 아직 서버가 내가 누군지 모른다.(인증이 되지 않는다)
- 쿠키에 담겨진 세션ID를 가지고 세션DB를 확인한다.
- 해당 세션ID로 kim유저라는 것을 인증하게 된다.
이 프로세스는 웹페이지내에서 다른 페이지로 이동할 때마다 반복된다.
중요한 점은 kim유저 정보는 모두 서버에 있다.
kim유저가 가지고 있는 것은 kim유저의 세션ID일 뿐이다.
쿠키는 세션ID를 전달하기 위한 매개체일 뿐이다.
토큰
세션을 이용해서 안드로이드나 ios를 만들 수 있지만, 쿠키는 브라우저에서 사용하는 개념이기 때문에 쿠키는 사용할 수 없다. 그래서 쿠키 대신에 토큰을 보내게 된다.
토큰은 이상하게 생긴 string이다.
해당 토큰을 서버에 보내고, 서버는 세션DB에서 해당 토큰과 일치하는 유저를 찾는다.
세션은 현재 로그인한 유저들의 모든 세션ID를 DB에 저장해야 한다.
요청이 들어올 때마다 서버는 쿠키를 받아서, 세션 ID를 보고 세션ID와 일치하는 유저를 찾는다. 유저가 늘어남에 따라 DB리소스가 더 필요하다.
JWT
JWT는 토큰형식이다.
JWT로 사용자 인증을 하게 되면 세션DB가 필요하지 않다.
- kim유저가 로그인을 하면 유저명과 비밀번호를 서버에 보낸다.
- 유저명과 비번이 맞다면, 서버는 DB에 뭔가를 생성하지 않는다.
- 서버는 kim유저의 특정정보 예를들면 유저ID를 가져다가 사인알고리즘을 이용해서 사인을 한다.
- 사인된 정보를 string형태로 보낸다.
- 이제 다시 kim이 요청을 하게 되면 세션ID와 같이 사인된c정보 또는 토큰을 서버에 보낸다.
- 서버는 토큰을 받으면 유효한지 체크한다.
세션과 jwt차이
세션에서는 세션ID만 주면 되었다. 세션에 대한 정보는 세션 DB에 저장되어 있기 때문이다. 페이지를 요청하면 서버는 세션ID를 DB에서 찾으면 되었다.
JWT에서는 서버는 유저를 인증하는데 필요한 정보를 토큰에 저장한다.
토큰을 우리에게 준다. 서버에서는 토큰이 유효한지만 판단하면 된다 DB를 거칠 필요가 없다. JWT는 암호화되지 않는다. 따라서 비밀번호와 같은 정보는 담으면 안된다.
토큰은 사인으로 하고 이를 통해 유효성을 검사한다.
쿠키 = 그냥 옮기는 시스템, 매개체
토큰 = 서버가 기억하는 이상하게 생긴 텍스트
JWT = 정보를 갖고 있는 토큰, DB없이 검증할 수 있다.
유저 인증을 위해서 JWT 혹은 세션을 사용할 수 있다.
