[Web] 로그인 인증 4가지 방법

 

참고 사이트: https://velog.io/@gusdnr814

0. 선 요약

1. session과 cookie를 이용한 인증
2. Access Token을 이용한 인증
3. Access Token + Refresh Token을 이용한 인증
4. OAuth 2.0을 이용한 인증

1. session과 cookie를 이용한 인증

sessionID는 쿠키에 담김

• 사용자가 로그인 요청시 서버에서는 계정 정보를 읽어 사용자를 확인한다.
• 승인시 사용자에게 고유ID값을 부여하여 session 저장소에 저장 후, 이와 연결되는 Session Id를 발급
• 사용자가 받은 session Id는 사용자 브라우저의 쿠키에 저장
• 이 후 요청시 마다 Session ID가 담긴 cookie를 같이 보냄 
• 서버에서는 이 쿠키를 받아 session 저장소에서 대조 후 응답 데이터 보냄 (쿠키에는 유저의 민감한 정보가 없어서 이렇게 하는거)

2. Access Token 이용한 인증

• JWT 
  • JSON Web Token의 약자로 인증에 필요한 정보들을 암호화 시킨 토큰 
  • Access Token으로 사용됨
  • 이것을 생성하기 위해서는 Header, Payload, Verify Signature 객체를 필요로 함Header

//Header 

{
  'alg': 'HS256',
  'typ': 'JWT'
}

// 토큰의 타입을 나타내는 typ 과 암호화 할 방식을 정하는 alg로 구성되어있음

// Payload
// 토큰에 담을 정보를 포함함. 보통 만료 일시, 발급 일시, 발급자, 권한 정보 등을 포함

{
  'sub': '1234567890',
  'name': 'John Doe',
  'admin': true,
  'iat': 1516239022
}

 

/** 
Verify Signature
Payload가 위변조 되지 않았다는 사실을 증명하는 문자열. 
Base64방식으로 인코딩 된 Header, Payload와 SECRET KEY를 더한 후 서명
SECRET KEY는 Verify Signature를 복호화 하기 위한 필수 정보
*/

HMACSHA256 {
  base64UrlEncode(header) + '.' +
  base64UrlEncode(payload),
  your-256-bit-secret
}

1. 사용자가 로그인을 했을 때 서버에서는 해당 정보가 유효한지 확인함.
2. 승인된다면 고유한 ID값을 부여해 payload에 정보를 넣음
3. JWT의 유효기간을 설정하고, secret_key를 통해 암호화 된 AccessToken을 HTTP 응답 헤더에 실어 보냄
4. 사용자는 AT를 저장 후, 이 후 요청시마다 토큰을 HTTP 요청 헤더에 실어 보냄
5. 서버는 해당 토큰의 Verify Signature을 secret key로 복호화 해서 유효 조작 여부 확인.
6. 검증 완료시, payload를 디코딩하여 사용자 ID에 맞는 데이터를 가져옴

• 세션 저장소가 따로 필요 없이 JWT 발급 후 검증만 거치면 돼서 추가 요구 저장소 X
• 토큰 기반으로 하는 다른 인증 시스텝 접근 가능해 확장성 뛰어남

• JWT는 한번 발급되면 유효기간 전까지 삭제가 불가능하기 때문에 중간에 해커에게 걸렸을 시 대처 방법x
• Payload 정보가 디코딩 되면 누구나 접근 가능해서 중요 정보 보관 x
• JWT의 길이가 길어서 인증 요청 많을 시 서버 자원 낭비 발생

3. Access Token + Refresh Token 이용한 인증

• 위에서 말한 JWT의 문제점을 해결하기 위해 유효기간을 짧게 하자니 유저가 로그인을 자주 해야해서 번거로움
• 이를 위한 해결책으로 Refresh Token을 이용함
• RT 또한 JWT 형태이며, AT보다 유효기간이 김. 
• RT의 유효기간을 길게 하고 AT의 유효기간을 짧게 잡아서, AT가 만료 될 시 RT를 참고해 새로 발급해주는 방식
• eg. RT가 2주, AT가 1시간 => 1시간 이후 만료됐을시 RT를 참고하여 AT를 새롭게 발급

RT를 유저가 따로 갖고 있다가 AT 만료시 끄집어 냄

• 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 HTTP 요청 헤더에 실어 요청을 보냅니다.
• Access Token을 검증하여 이에 맞는 데이터를 보냅니다.
• 시간이 지나 Access Token이 만료됐다고 보겠습니다.
• 사용자는 이전과 동일하게 Access Token을 HTTP 요청 헤더에 실어 보냅니다.
• 서버는 Access Token이 만료됨을 확인하고 권한 없음을 신호로 보냅니다.
• 사용자는 Refresh Token과 Access Token을 HTTP 요청 헤더에 실어 보냅니다.
• 서버는 받은 Access Token이 조작되지 않았는지 확인한 후, HTTP 요청 헤더의 Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해줍니다.
• 서버는 새로운 Access Token을 HTTP 응답 헤더에 실어 다시 API 요청을 진행합니다.

4. OAuth 2.0

• Resource Owner : 일반 사용자
• Client : 우리가 만든 웹 어플리케이션
• Authorization Server : 권한 관리 및 Access Token, Refresh Token을 발급해주는 서버
• Resource Server : OAuth 2.0을 관리하는 서버의 자원을 관리하는 곳