로그인의 4가지 방식

---

세션과 쿠키를 이용한 인증

1. 사용자가 로그인을 함
2. 서버에서는 계정 정보를 읽어 사용자 정보를 확인 후 고유한 ID 값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 Session ID를 발급
3. 사용자는 서버에서 해당 세션ID를 받아 쿠키에 저장을 한 후, 인증이 필요한 요청마다 쿠키를 헤더에 실어 보냄
4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져옴
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내줌

세션 쿠키🍪 방식의 인증은 기본적으로 세션 저장소를 필요로 함(Redis를 많이 사용).
세션 저장소는 로그인을 했을 때 사용자의 정보를 저장하고 열쇠가 되는 세션ID값을 만듦.
그리고 HTTP 헤더에 실어 사용자에게 돌려보냄.
그러면 사용자는 쿠키로 보관하고 있다 인증이 필요한 요청에 쿠키(세션ID)를 넣어 보냄.
웹 서버에서는 세션 저장소에서 쿠키(세션ID)를 받고 저장되어 있는 정보와 매칭시켜 인증을 완료함

❓쿠키와 세션의 차이

• 쿠키
  => 방문자의 정보를 방문자 컴퓨터의 메모리에 저장
• 세션
  => 웹 서버가 세션 아이디 파일을 만들어 서비스가 돌아가고 있는 서버에 저장

세션과 쿠키를 통한 인증 방식의 장점

1. 세션/쿠키 방식은 기본적으로 쿠키를 매개로 인증을 거침
   여기서 쿠키는 세션 저장소에 담긴 유저 정보를 얻기 위한 열쇠임. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체(세션 ID)는 유의미한 값을 갖고있지 않음(중요 정보는 서버 세션에 담김)
   
   
2. 사용자마다 고유의 Sesson ID값을 발급받게 됨. 그렇게 되면 서버에서는 쿠키 값을 받았을 때 일일이 회원정보를 확인할 필요 없이 바로 어떤 회원인지를 확인할 수 있어 서버의 자원에 접근하기 용이
   
   

세션과 쿠키를 통한 인증 방식의 단점

1. 쿠키에 사용자 정보를 담아 인증을 거치는 것 보다 안전하지만, 해커가 쿠키를 탈취한 후 그 쿠키를 이용해 HTTP 요청을 보내면 서버는 사용자로 오인해 정보를 전달하게 됩니다.(세션 하이재킹 공격)
   
   해결책?
   • HTTPS를 사용해 요청 자체를 탈취해도 안의 정보를 읽기 힘들게 한다.
   • 세션에 유효시간⏳을 넣어준다

2. 서버에서 세션 저장소를 사용하기 때문에 서버에서 추가적인 저장공간을 필요로 하게되고 부하가 증가됨.

---

Access Token을 통한 인증

JWT(Json Web Token)

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

Header

alg ➡ 암호화할 방식
typ ➡ 토큰의 타입

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

Payload

Payload는 토큰에 담을 정보를 포함
여기서 하나의 정보 조각을 클레임이라고 함. 클레임의 종류로는 Registered, Public, Private로 3가지가 존재
보통 만료 일시, 발급 일시, 발급자, 권한정보 등을 포함

{
  "memberId": "aesop0817",
  "memberName": "John Do",
  "authorityType": "MANAGER"
  "iat": 1516239022
}

Verify Signature

Verify Signature는 Payload가 위변조되지 않았다는 사실을 증명하는 문자열
Base64 방식으로 인코딩한 Header, Payload 그리고 SECRET KEY를 더한 후 서명됨

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

Header, Payload는 인코딩될 뿐, 따로 암호화되지 않음
따라서 Header, Payload는 누구나 디코딩하여 확인할 수 있기에 정보가 쉽게 노출될 수 있지만 Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없음

만약에 해커가 사용자의 토큰을 훔쳐 Payload의 데이터를 변경하여 토큰을 서버로 보낸다면, 서버에서 Verify Signature을 검사함
여기서 Verify Signature는 해커의 정보가 아닌 사용자의 정보를 기반으로 암호화되었기 때문에 해커가 변경한 정보로 보낸 토큰은 유효하지 않은 토큰으로 간주함❗️

즉, 사용자의 SECRET KEY를 알지 못하면 토큰을 조작할 수 없음

동작⏯️방식

사용자가 로그인을 함

서버에서는 계정 정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID값을 부여하고 Payload에 정보를 넣음

JWT 토큰의 유효기간을 설정

SECRET KEY를 통해 암호화된 Access Token을 HTTP 응답 헤더에 실어 보냄

사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 HTTP 요청 헤더에 실어 보냄

서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효 기간을 확인

검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져옴

Access Token을 통한 인증의 장점

1. 간편합니다. 세션/쿠키는 별도의 저장소의 관리가 필요함
   그러나 JWT는 발급한 후 검증만 하면 되기 때문에 추가 저장소가 필요하지 않음
   이는 Stateless 한 서버를 만드는 입장에서는 큰 강점이며 이는 서버를 확장하거나 유지,보수하는데 유리함
   
   
2. 확장성이 뛰어남
   토큰 기반으로 하는 다른 인증 시스템에 접근이 가능
   
   

Access Token을 통한 인증의 단점

1. JWT는 한 번 발급되면 유효기간이 완료될 때까지는 계속 사용이 가능하며 중간에 삭제가 불가능하므로 따라서 해커에 의해 정보가 털린다면 대처할 방법이 없음

   해결책
   =>Refresh Token을 추가적으로 발급하여 해결하는 방식

2. Payload 정보가 디코딩하면 누구나 접근할 수 있기에 중요한 정보들을 보관할 수 없음(ex.비밀번호)

3. JWT의 길이가 길기 때문에, 인증 요청이 많아지면 서버의 자원낭비가 발생

---

Access Token + Refresh Token을 이용한 인증

Access Token(JWT)를 통한 인증 방식의 문제는 만일 제 3자에게 탈취당할 경우 보안에 취약하다는 점임

유효기간을 짧게 설정하면 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 유저 친화적이지 못함
그렇다고 유효기간을 늘리자면, 토큰을 탈취당했을 때 보안에 더 취약해지게 됨

Refresh Token은 Access Token과 똑같은 형태의 JWT
처음에 로그인을 완료했을 때 Access Token과 동시에 발급되는 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 발급해주는 열쇠🔑가 됨
(만료===유효기간을 지났다)

❗️Access Token은 탈취당하면 정보가 유출되는건 동일
다만 짧은 유효기간 안에만 사용이 가능하기에 더 안전하다는 의미

동작⏯️방식

1. 사용자가 ID, PW로 로그인을 함
2. 서버에서는 회원 DB에서 값을 비교
3. 로그인이 완료되면 Access Token, Refresh Token을 발급하여 Http 응답 헤더에 실어 보냄. 회원 DB에 일반적으로 Refresh Token값을 저장해둠
4. 사용자는 Refresh Token을 안전한 저장소에 저장 후, Access Token을 Http 요청 헤더에 실어 요청을 보냄
5. Access Token을 검증해 맞는 데이터를 보내줌

Access Token은 보안🔐상의 이유로 유효기간을 짧게 설정하는 것이 좋음
만료됐을 경우 어떻게 될까❓

6. Access Token이 만료됨
7. 사용자는 이전과 동일하게 Access Token을 Http 요청 헤더에 실어 보냄
8. 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보냄
9. 사용자는 Refresh Token과 Access Token을 함께 서버로 보냄
10. 서버는 전달받은 Access Token이 조작되지 않았는지 확인 후, Refresh Token과 사용자 DB에 저장되어있던 Refresh Token을 비교. 동일하다면 새로운 Access Token을 발급
11. 서버는 새로운 Access Token을 헤더에 실어 다시 API 요청을 진행

Access Token+Refresh Token을 통한 인증의 장점

1. 기존에 Access Token만으로 인증하는 방식보다 안전
   
   

Access Token+Refresh Token을 통한 인증의 단점

1. 검증 프로세스가 길어졌으므로 구현이 복잡해짐
2. Access Token 만료시 새롭게 발급하는 과정에서 Http 요청 횟수가 많음
   => 서버 자원의 낭비로 귀결될 수 있음

---

Oauth 2.0을 통한 인증

Oauth

외부 서비스의 인증 및 권한 부여를 관리하는 범용적인 프로토콜

Oauth 2.0

2007년에 Oauth 1.0이 발표되었지만 네트워크 시장이 커짐에 따라 한계가 드러났고 2012년에 발표된 Oauth 2.0이 현재까지 사용되고 있음

특징

• 모바일에서도 사용이 용이
• 반드시 Https를 사용하므로 보안 강화
• Access Token의 만료기간 생김

	OAuth 2.0 주요 용어
Authentication	인증, 접근 자격이 있는지 검증하는 단계
Authorization	인가, 자원에 접근할 권한을 부여하는 것. 인가가 완료되면 리소스 접근 권한이 담긴 Access Token이 클라이언트에게 부여
Access Token	리소스 서버에게서 리소스 소유자의 보호된 자원을 획득할 때 사용되는 만료 기간이 있는 Token
Refresh Token	Access Token 만료시 이를 갱신하기 위한 용도로 사용하는 Token. Refresh Token은 일반적으로 Access Token보다 만료 기간이 김

Resource Owner : 일반 사용자

Client : 우리가 만든 웹 어플리케이션

Authorization Server : 권한 관리 및 Access Token, Refresh Token을 발급해주는 서버

Resource Server : OAuth 2.0을 관리하는 서버의 자원을 관리하는 곳

권한 부여 방식

1. Authorization Code Grant(권한 부여 승인 코드 방식)

권한 부여 승인을 위해 자체 생성한 Authorization Code를 전달하는 방식으로 많이 쓰이고 기본이 되는 방식

간편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식

보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용

Refresh Token의 사용이 가능한 방식

• Resource Owner가 Client에게 인증 요청을 함

• Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(Facebook, Google 로그인 url)을 보냄

• Resource Owner는 해당 Request를 통해 인증을 진행하고 인증을 완료했다는 신호로 Authorization Grant를 url에 실어 Client에게 보냄

• Client는 해당 권한 증서를 Authorization Server에 보냄

• Authorization Server는 권한 증서를 확인 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 정보를 발급해줌

• Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘김

• Resource Owner가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청

• Resource Server는 Access Token이 유효한 지 확인 후, Client에게 자원을 보냄

• 만일 Access Token이 만료됐거나 위조되었다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급 받음

• 그 후 다시 Resource Server에 자원을 요청

• 만일 Refresh token도 만료되었을 경우, Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야함

2. Implicit Grant(암묵적 승인 방식)

자격증명을 안전하게 저장하기 힘든 클라이언트(ex: JavaScript등의 스크립트 언어를 사용한 브라우저)에게 최적화된 방식자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식입니다. Refresh Token의 사용도 가능

암시적 승인 방식에서는 권한 부여 승인 코드 없이 바로 Access Token이 발급 됨
Access Token이 바로 전달되므로 만료기간을 짧게 설정하여 누출의 위험을 줄일 필요성 있음

Refresh Token 사용이 불가능한 방식이며, 이 방식에서 권한 서버는 client_secret를 사용해 클라이언트를 인증하지 않음
Access Token을 획득하기 위한 절차가 간소화되기에 응답성과 효율성은 높아지지만 Access Token이 URL로 전달됨

로그인이 완료되면 권한 서버는 Authorization Code가 아닌 Access Token를 redirect_url로 바로 전달

3. Client Credentials Grant(클라이언트 자격증명 승인 방식)

클라이언트의 자격증명만으로 Access Token을 획득하는 방식
자신의 서비스에서 제공하는 어플리케이션일 경우에만 사용되는 인증 방식
Refresh Token의 사용도 가능

이 방식은 권한 서버, 리소스 서버, 클라이언트가 모두 같은 시스템에 속해 있을 때 사용되어야 하는 방식임

4. Client Credentials Grant(클라이언트 자격증명 승인 방식)

클라이언트 자격증명만으로 Access Token을 획득하는 방식

OAuth2의 권한 부여 방식 중 가장 간단한 방식으로 클라이언트 자신이 관리하는 리소스 혹은 권한 서버에 해당 클라이언트를 위한 제한된 리소스 접근 권한이 설정되어 있는 경우 사용
자격증명을 안전하게 보관할 수 있는 클라이언트에서만 사용되어야 하며, Refresh Token은 사용할 수 없음

---

참조 ※

로그인-인증-4가지-방법
쉽게 알아보는 서버 인증-2편
Oauth 2.0 동작 방식의 이해