서버 인증

정리 원본 링크 : 쉽게 알아보는 서버 인증 3편

• OAuth에 대한 내용

OAuth

• Oauth는 외부 서비스의 인증 및 권한 부여를 관리하는 범용적인 프로토콜
  • 외부 서비스
    • 우리가 만들고 있는 서비스를 말함
    • 외부 서비스를 위한 서비스인 OAuth는 우리 서비스의 인증 및 권한 부여에 대한 관리를 대행해줌
  • 권한
    • OAuth는 인증 뿐만 아니라 권한도 관리
    • 사용자의 권한에 따라 접근할 수 있는 데이터가 다르도록 설정이 가능
  • 프로토콜
    • 특정한 프로그램을 지칭하는게 아니라 일종의 규격
    • Facebook, Google, Naver 등은 OAuth라는 규격에 맞춰 인증 및 권한을 대행 관리 해줌

• 한 가지 명심해야할 점은 세션 쿠키 방식이나 토큰 기반 인증 방식을 완전히 대체하는게 아니라는 점
  • 즉 SNS 로그인 기능을 넣더라도 결국은 세션 쿠키 방식이나 토큰을 활용해 인증을 거쳐야 함

OAuth 2.0

• 현재 대다수가 사용하고 있는 Oauth는 2.0 버전
• 2007년 OAuth 1.0의 초안이 발표된 이후 많이 알려지게 되었음
  • 그러나 점점 커져가는 네트워크 시장에서 한계가 나타나기 시작했고 2012년 Oauth 2.0을 새롭게 제시

• Oauth 2.0에서 크게 바뀐 점은 다음과 같음
  • ❶ 모바일 어플리케이션에서도 사용이 용이해짐
  • ❷ 반드시 HTTPS를 사용하기에 보안이 강화됨
  • ❸ Access Token의 만료기간이 생김

• OAuth 2.0의 인증 방식은 크게 4가지
  • Authorization Code Grant
  • Implicit Grant
  • Resource Owner Password Credentials Grant
  • Client Credentials Grant
• 각 인증 방식에는 장단점이 존재
• 여기서는 가장 많이 쓰이는 Authorization Code Grant 방식을 예로 들어 동작 순서를 적을 예정

OAuth 2.0의 동작 순서

• Resource Owner : User, 즉 일반 사용자를 칭함
• Client : 우리가 관리하는 어플리케이션 서버
  • User와 혼동될 수 있는데 아님
• Authorization Server : 권한을 관리하는 서버
  • Access Token, Refresh Token을 발급•재발급 해주는 역할을 함
• Resource Server : OAuth2.0을 관리하는 서버(Google, Facebook, Naver 등)의 자원을 관리하는 서버
  • 주의할 점은 우리가 만드는 서버의 자원을 관리하는 곳이 아님
  • Oauth 2.0 관리 서버의 자체 API를 의미

• ① Resource Owner(일반 사용자)가 Client(어플리케이션 서버)에게 인증 요청을 함
• ② Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(Facebook, Google 로그인 url)을 보냄
• ③ Resource Owner는 해당 Request를 통해 인증을 진행하고 인증을 완료했다는 신호로 권한증서(Authorization Grant)를 url에 실어 Client에게 보냄
• ④ Client는 해당 Authorization Grant를 Authorization Server에 보냄
• ⑤ Authorization Server는 Authorization Grant를 확인한 후, Resource Owner가 해당 서비스의 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함)등을 발급해줌
• ⑥ 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에게 넘겨야함
  • 이는 Resource Owner가 다시 로그인 하라는 뜻

Tip!

• Access Token & Refresh Token을 이용한 인증 방식과 유사
• 하지만 Access Token & Refresh Token을 이용한 인증 방식은 한 서버에서 모두 관리하는 반면, OAuth에서는 Authorization Server에서 인증 + 권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 함

Tip!

• Oauth 2.0 은 우리가 이전에 봤던 사용자 - 서버 구조가 아닌 사용자 - 서버 - OAuth 서버
• 우리가 만들 서비스들의 인증을 돕기 위한 서비스가 바로 OAuth
  • Resource Server는 우리의 서버가 아닌 Oauth를 관리하는 서버의 일부임을 명심해야 함

SNS 로그인

• ① Resource Owner(사용자)가 서버에게 로그인을 요청
• ② 서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보냄
• ③ 사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한 증서(Authorization Code Grant)를 담아 서버에게 보냄
• ④ 서버는 해당 권한 증서를 Facebook의 Authorization Server로 요청
• ⑤ Authorization Server는 권한 증서를 확인 후, Access Token, Refresh Token, 유저의 정보(고유 id 포함) 등을 돌려줌
  • 여기서 프로필 이미지나 이메일 주소, 이름 등을 얻을 수도 있는데 이는 초기에 관리자가 권한 설정을 어디까지 하느냐에 따라 다름
  • 페이스북 이름에 대해서만 접근할 수 있는 권한을 설정하면 이름 값만 Authorization Server에서 돌려줄 것
• ⑥ 받은 고유 id를 key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행
• ⑦ 로그인이 완료 되었다면 세션 쿠키 방식 또는 토큰 기반 인증 방식을 통해 사용자의 인증을 처리

Tip!

• 우리가 만들 서버에서 OAuth를 이용하기 위해서는 사전에 OAuth에 등록하는 과정이 필요
• 등록 후 APP_ID와 CLIENT_ID 등을 보내야 OAuth에서는 어느 서비스인지를 알 수 있음

Tip!

• 페이스북 로그인을 인증을 이용하는 경우, 대부분은 Resource Server(페이스북 자체 API)를 사용하지 않기 때문에 Access Token, Refresh Token은 실제로 쓰이지 않음
• 우리의 서버에서 Access Token을 검증할 수도 없을 뿐더러 인증의 수단으로 활용하기엔 부족한 점이 많음
• 따라서 보통 Authorization Server로 부터 얻는 고유 id값을 활용해서 DB에 회원 관리를 진행

SNS 로그인의 장점

• ❶ 회원가입이라는 귀찮은 절차를 없애고 사용자가 빠르게 회원가입을 할 수 있음
• ❷ 접근하고 싶은 정보들은 사용자들이 미리 권한 내용을 확인하고 허락하기에 쉽게 접근할 수 있음