1. 세션과 쿠키를 이용한 인증
1. 사용자 로그인
2. 서버에서는 계정 정보를 읽어 사용자를 확인한 후, 사용자에게 고유한 ID값을 부여하여 세션 저장소에 저장한 후, 이와 연결되는 Session ID를 발급한다.
3. 서버는 HTTP 응답 헤더에 발급된 Session ID를 실어 보낸다. 이후 매 요청마다 HTTP 요청 헤더에 Session ID가 담킨 쿠키를 실어 보낸다.
4. 서버에서는 쿠키를 받아 세션 저장소에서 대조를 한 후 대응되는 정보를 가져온다.
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.
장점
- 사용자의 정보는 세션 저장소에 저장되고, 쿠키는 그 저장소를 통과할 수 있는 출입증 역할을 한다. 따라서 쿠키가 담긴 HTTP 요청이 도중에 노출되더라도 쿠키 자체에는 유의미한 값을 갖고있지 않아서 쿠키에 사용자 정보를 담아 인증을 거치는 것 보다 안전하다.
- 각 각의 사용자는 고유의 Session ID를 발급 받기 때문에 일일이 회원 정보를 확인할 필요가 없어 서버 자원에 접근하기 용이하다.
단점
- 쿠키에 사용자 정보를 담아 인증을 거치는 것 보다 안전하지만, 해커가 쿠키를 탈취한 후 그 쿠키를 이용해 HTTP 요청을 보내면 서버는 사용자로 오인해 정보를 전달하게 된다. 이를 세션 하이재킹 공격이라고 합니다. (해결책: HTTPS 프로토콜 사용과 세션에 만료 시간을 넣어준다)
- 서버에서 세션 저장소를 사용하기 때문에 추가적인 저장공간을 필요로 한다.
2. Access Token을 이용한 인증
JWT(JSON Web Token)
인증에 필요한 정보들을 암호화시킨 토큰을 말하며, Access Token으로 사용됩니다. JWT를 생성하기 위해서는 Header, Payload, Verify Signature 객체를 필요로 한다.
Header
{
'alg':'HS256', //암호화방식
'typ':'JWT' //토큰타입
}
Payload
Payload는 토큰에 담을 정보를 포함한다. 하나의 정보 조각을 클레임으로 부른다. 클레임의 종류로는 Registered, Public, Private로 3가지가 존재한다. 보통 만료 일시, 발급 일시, 발급자, 권한정보 등을 포함.
{
'sub':'1234567890',
'name':'Jphn Doe',
'admin':true,
'iat:'1516239022
}
Verify Signature
Verify Signature는 Payload가 위변조되지 않았다는 사실을 증명하는 문자열. Base64 방식으로 인코딩한 Header, Payload 그리고 SECRET KEY를 더한 후 서명된다.
HMACSHA256{
base64UrlEncode(header) + '.' +
base64UrlEndocde(payload),
your-256-bit-secret
}
Header, Payload는 인코딩될 뿐, 따로 암호화되지 않는다. 따라서 Header, Payload는 누구나 디코딩하여 확인할 수 있기에 정보가 쉽게 노출될 수 있다. 하지만 Verify Signature는 SECRET KEY를 알지 못하면 복호화할 수 없다.
만약에 해커가 사용자의 토큰을 훔쳐 Payload의 데이터를 변경하여 토큰을 서버로 보낸다면, 서버에서 Verify Signature을 검사하게 된다. 여기서 Verify Signature는사용자의 SECRET KEY를 기반으로 암호화되었기 때문에 해커가 변경한 정보로 보낸 토큰은 유효하지 않은 토큰으로 간주한다.
1. 사용자 로그인
2. 서버에서 계정 정보를 읽어 사용자 확인 후, 사용자의 고유한 ID값을 부여하고 Payload에 정보주입 한다.
3. JWT 토큰의 유효기간을 설정한다.
4. SECRET KEY를 통해 암호화된 Access Token을 HTTP 응답 헤더에 실어보낸다.
5. 사용자는 Access Token을 받아 저장한 후, 인증이 필요한 요청마다 토큰을 HTTP 요청 헤더에 실어 보낸다.
6. 서버에서는 해당 토큰의 Verify Signature를 SECRET KEY로 복호화한 후, 조작 여부, 유효 기간을 확인한다.
7. 검증이 완료된다면, Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.
장점
- 간편하다. 세션과 쿠키를 이용한 인증은 별도의 세션 저장소의 관리가 필요하다. 그러나 JWT는 발급 후 검증만 거치면 되기 때문에 추가 저장소가 필요없다.
- 확장성이 뛰어나다. 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능.
단점
- JWT는 한 번 발급되면 유효기간이 완료될 때까지는 계속 사용이 가능하며 중간에 삭제가 불가능 하다. 따라서 해커에 의해 정보가 털린다면 대처할 방법이 없다.(Refresh Token을 추가적으로 발급하여 해결.)
- Payload 정보가 디코딩하면 누구나 접근할 수 있기에 중요한 정보들을 보관할 수 없다.
- JWT의 길이가 길기 때문에, 인증 요청이 많아지면 서버의 자원낭비가 발생한다.
2-1. Access Token + Refresh Token을 이용한 인증
Refresh Token은 Access Token과 같은 형태인 JWT입니다. Refresh Token은 Access Token보다 긴 유효기간을 가지고, Access Token이 만료됐을 때 새로 발급해주는 열쇠가 된다. 예를 들어 Refresh Token의 유효 기간이 2주, Access Token의 유효 기간이 1시간이라고 한다면, 2주 동안 Access Token이 만료 되는 1시간 주기마다 Access Token을 새롭게 발급받을 수 있다.
1. 사용자 로그인
2. 서버에서는 회원 DB에서 값을 비교.
3. 로그인이 완료되면 Access Token, Refresh Token을 발급하여 HTTP 응답 헤더에 실어 보낸다. 이때 일반적으로 회원 DB에 Refresh Token을 저장해둔다.
4. 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 HTTP 요청 헤더에 실어 요청을 보낸다.
5. Access Token을 검증하여 이에 맞는 데이터를 보낸다.
6. (시간이 지나 Access Token이 만료 시) 사용자는 이전과 동일하게 Access Token을 HTTP 요청 헤더에 실어 보낸다.
7. 서버는 Access Token이 만료됨을 확인하고 권한 없음을 신호로 보낸다.
8. 사용자는 Refresh Token과 Access Token을 HTTP 요청 헤더에 실어 보낸다.
9. 서버는 받은 Access Token이 조작되지 않았는지 확인한 후, HTTP 요청 헤더의 Refresh Token과 사용자의 DB에 저장되어 있던 10. Refresh Token을 비교한다. Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급한다.
11. 서버는 새로운 Access Token을 HTTP 응답 헤더에 실어 다시 API 요청을 진행한다.
장점
Access Token의 유효 기간이 짧기 때문에, 기존의 Access Token만을 이용한 인증보다 안전하다.
단점
구현이 복잡하고, Access Token이 만료될 때마다 새롭게 발급하는 과정에서 서버의 자원 낭비가 생긴다.
3. OAuth 2.0을 이용한 인증
OAuth 2.0(Open Authorization 2.0, OAuth2)은 인증을 위한 개방형 표준 프로토콜.
이 프로토콜에서는 Third-Party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공한다. (구글, 페이스북, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공)
OAuth2.0 주요특징 3가지
1. 모바일에서도 사용이 용이하다.
2. 반드시 HTTPS를 사용하므로 보안이 강화되었다.
3. Access Token의 만료 기간이 생김.
가장 범용적으로 쓰이는 Authorization Code Grant_권한 부여 승인 코드 방식 (OAuth 2.0의 인증 방식은 4가지가 있음)
편 로그인 기능에서 사용되는 방식으로 클라이언트가 사용자를 대신하여 특정 자원에 접근을 요청할 때 사용되는 방식입니다. 보통 타사의 클라이언트에게 보호된 자원을 제공하기 위한 인증에 사용됩니다. Refresh Token의 사용이 가능한 방식이다.
인증 순서
Resource Owner : 일반 사용자
Client : 우리가 만든 웹 어플리케이션
Authorization Server : 권한 관리 및 Access Token, Refresh Token을 발급해주는 서버
Resource Server : OAuth 2.0을 관리하는 서버의 자원을 관리하는 곳
권한 부여 승인 요청 시 response_type을 code로 지정하여 요청한다. 이후 클라이언트는 권한 서버에서 제공하는 로그인 페이지를 브라우저를 띄워 출력한다. 이 페이지를 통해 사용자가 로그인을 하면 권한 서버는 권한 부여 승인 코드 요청 시 전달받은 redirect_url로 Authorization Code를 전달. Authorization Code는 권한 서버에서 제공하는 API를 통해 Access Token으로 교환된다.
[Authorization Code 획득 후 해당 Code로 Access Token 획득]
/**
* Step 1: Authorization
*/
//Request
(GET)/authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fc
//Response
https://client.example.com/cb?code=SplxlOBeZQQYbYS6WxSbIA&state=xyz
/**
* Step 2: Access Token
*/
//Request
(POST) /token
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb
//Response
{
"access_token":"2YotnFZFEjr1zCsicMWpAA",
"token_type":"example",
"expires_in":3600,
"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA",
"example_parameter":"example_value"
}
4. SNS 로그인
1. 사용자가 서버에게 로그인을 요청.
2. 서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보낸다.
3. 사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한 증서를 담아 서버에게 보낸다.
4. 서버는 해당 권한 증서를 Facebook의 Authorization Server로 요청한다.
5. 서버는 권한 증서를 확인 후, Access Token, Refresh Token, 유저의 정보를 돌려준다.
6. 받은 고유 ID를 Key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행한다.
7. 로그인이 완료되었다면 세션과 쿠키 , 토큰 기반 인증 방식을 통해 사용자의 인증을 처리한다.
참고 사항
서버에서 OAuth를 이용하기 위해서는 사전에 OAuth에 등록하는 과정이 필요하다. 개발자 사이트에서 웹 어플리케이션을 등록 후 APP_ID와 CLIENT_ID 등을 보내야 OAuth 에서는 어느 서비스인지를 알 수 있다.
페이스북 로그인을 인증을 이용하는 경우, 대부분은 Resource Server(페이스북 자체 API)를 사용하지 않는다. 따라서 Access Token, Refresh Token은 실제로 쓰이지 않는다. 우리의 서버에서 Access token을 검증할 수도 없을 뿐더러 인증의 수단으로 활용하기엔 부족한 점이 많다. 따라서 보통 Authorization Server로 부터 얻는 고유 ID값을 활용해서 DB에 회원관리를 진행한다.
댓글