로그인 인증 (Session/Cookie, Token, OAuth, SNS)

Session, Cookie

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

* 쿠키가 사용자 개념에서 더 큰 범주로 세션ID를 쿠키로 저장하는 것이다. 따라서 세션ID를 쿠키라고 봐도 동일하다.

 

1. 사용자가 로그인을 한다.

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

3. 세션 저장소에 저장한 후

4. 서버와 연결되는 세션 ID를 발행한다.

5. 사용자는 서버에서 해당 세션 ID를 받아 쿠키에 저장을 한다.

6. 사용자는 인증이 필요한 요청마다 쿠키를 헤더에 실어 서버에 보낸다.

7. 서버에서 쿠키를 받아 세션 저장소에서 대조를 한 후

8. 세션 저장소에서 대응되는 정보를 가져온다.

9. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.

---

Token (JWT)

JWT는 세션, 쿠키와 함께 모바일, 웹의 인증을 책임지는 대표이다. JWT는 Json Web Token약자로 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다. 위 세션, 쿠키 방식과 유사하나 사용자는 Access Toekn(JWT)을 HTTP 헤더에 실어 서버로 보내게 된다.

 

 

토큰을 만들기 위해서는 Header, Payload, Verify Signature가 필요하다.

Header : 위 3가지 정보를 암호활 방식(alg), 타입(type)이 들어간다.

Playload : 서버에서 보낼 데이터로 일반적으로 유저의 고유ID값, 유효기간이 들어간다.

Verify Signature : Base64 방식으로 인코딩한 Header, payload 그리고 SECRET KEY를 더한 후 서명된다.

 

최종 결과로 Encoded Haeder + "." + Encoded Payload + "." + Verify Signature

Header, Payload는 인코딩될 뿐 따로 암호화하지 않아 JWT 토큰에서 누구나 디코딩할 수 있다. 그렇다면 비밀번호가 노출되는 것 아닌가 할 수 있으나 Verify Signature의 SECURET KEY를 알지 못하면 복호화할 수 없다.

 

1. 사용자가 서버에 로그인한다.

2. 서버에서는 계정정보를 읽어 사용자를 확인 후, 사용자의 고유한 ID를 부여한 후, 기타 정보와 함께 Payload에 넣는다.

3. JWT 토큰의 유효기간을 설정한다.

4. 암호화할 SECRET KEY를 이용해 ACCESS TOKEN 을 발급한다.

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

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

7. 검증이 완료되면 Payload를 디코딩하여 사용자의 ID에 맞는 데이터를 가져온다.

---

Access Token + Refresh Token

 

Refresh Token은 Access Token과 똑같은 형태의 JWT로 처음에 로그인을 완료할 때 Access Token와 Refresh Token이 동시에 발급된다. Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료되면 새로 발급해주는 열쇠가 된다.

 

1. 사용자가 서버에 로그인한다.

2. 서버에서는 회원DB에서 값을 비교한다. (보통 패스워드는 암호화해서 들어간다.)

3~4. 로그인이 완료되면 Access Token, Refresh Token을 발근한다. (일반적으로 회원DB엔 Refresh Token을 저장한다.)

5. 사용자는 Refresh Token은 안전한 장소에 저장한 후 Access Token을 헤더에 실어 요청을 보낸다.

6~7. Access Token을 검증하여 이에 맞는 데이터를 보낸다.

8~9. 시간이 지나 Access Token이 만료된 상태에서 사용자는 이전과 동일하게 Access Token을 헤더에 실어 보낸다.

10~11. 서버는 Access Toekn이 만료됨을 확인 후 권한 없음을 신호로 보낸다.

12. 사용자는 Refresh Token과 Access Token을 함께 서버로 보낸다.

13. 서버는 받은 Access Token이 조작되지 않았는지 확인 후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교한다. Token이 동일하고 유효기간이 남았다면 새로운 Access Token을 발급한다.

14. 서버는 새로은 Access Token을 헤더에 실어 다시 API요청을 진행한다.

---

OAuth 2.0

 

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

명심해야할 부분은 위 내용(사용자 - 어플리케이션 서버)인증 절차였던 세션, 쿠키 그리고 토큰 기반 인증 방식을 완전히 대체하는 것이 아니다. 즉, SNS 로그인 기능을 넣더라도 위 인증 방식을 거쳐야한다.

 

OAuth 2.0에서 자주 사용되는 Authorization Code Grant 방식으로 작성된다.

 

Authorization Server : 권한을 관리하는 서버로 Access Token, Refresh Token을 발급 및 재발급하는 역할이다.

Resource Server : OAuth 2.0을 관리하는 서버(Goggle, Facebook, Naver 등)의 자원을 관리하는 서버이다. 주의할 점은 우리가 만든 서버의 자원을 관리하는 곳이 아니다. OAuth 2.0 관리 서버의 자체 API를 의미한다.

 

1. Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 한다.

2. Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(Facebook, Google 로그인 URL)을 보낸다.

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

4. Client는 해당 권한증서(Authorization Grant)를 Authorization Server에 보낸다.

5. Authorization Server는 권한증서를 확인 후, 유저가 맞다면 Client에게 Access Token, Refresh Token 그리고 유저의 프로필 정보 등을 발급해준다.

6. Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘긴다.

7. Resouce Owner(사용자)가 Resouce Server에 자원이 필요하면 Client는 Access Token을 담아 Resource Server에 요청한다.

8. Resouce Server는 Access Token이 유효한지 확인 후 Client에게 자원을 보낸다.

9. 만약 Access Toekn이 만료되거나 위조됐다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급 받는다.

10. 그 후 다시 Resource Server에 자원을 요청한다.

11. 만일 Refresh Token도 만료라면, Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야 한다. (사용자에게 다시 로그인하라는 의미)

---

SNS 로그인

 

SNS 로그인은 간단하게 봤을 때 OAuth 2.0 + 서버 인증(세션, 쿠키, 토큰기반 인증)으로 구성된다.

 

1. 사용자(Resource Owner)가 서버에게 로그인을 요청한다.

2. 서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보낸다.

3. 사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한증서(code)를 담아 서버에게 보낸다.

4. 서버는 해당 권한 증서를 Facebook의 Authorization Server로 요청한다.

5. 서버는 권한 증서를 확인 후, Access Token, Refresh Token, 유저의 정보(고유 id 포함)을 돌려보낸다.

6. 받은 고유 id를 key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행한다.

7. 로그인이 완료되면 세션, 쿠키, 토큰 기반 인증 방식을 통해 사용자의 인증을 처리한다.

 

---

 

 

https://tansfil.tistory.com/58?category=475681

https://tansfil.tistory.com/59?category=475681

https://tansfil.tistory.com/60?category=475681