OAuth 2.0

JWT 토큰 인증방식에 대해 공부하다가 팀원에게 OAuth라는 인증방식이 있다는 이야기도 듣게 되어 찾아봤는데 평상시에 너무 궁금했던 부분이여서 공부하던 JWT 토큰 방식은 던져두고 OAuth를 공부하게 되었다. 그래도 아쉬움에 공부했던 쿠키 & 세션 방식에 대해 간단하게 작성하고 OAuth에 대해 풀어보자 한다.

---

로그인 방식

로그인 방식에 대해 알아보기 전에 HTTP의 특성에 대해 알면 이해하는데 도움이 되는데 바로 서버는 클라이언트의 요청을 끝내면 연결을 끊어버린다는 것이다. 그렇다면 사용자가 웹서비스를 사용할 때 매번 로그인을 해야하는가? 아니다! 이러한 문제를 해결하기 위해 나온 것이 cookie, session 등의 로그인 방식들이다. 다음의 로그인 방식들에 대해 알아보자

• Cookie

• Cookie & Session

• JWT 기반 인증

• OAuth 2.0

  ---

Cookie

• 쿠키 방식은 서버가 클라이언트측에 저장하고 싶은 정보를 set-cookie에 담게 된다.
• 클라이언트는 서버에 요청을 보낼 때 마다 저장된 쿠키를 요청 헤더의 cookie에 담아 보내는 방식이다.

Cookie & Session

• 세션은 비밀번호 등 클라이언트의 인증 정보를 쿠키가 아닌 서버에 저장관리하는 방식이다.
• 서버가 클라이언트의 로그인 요청에 인증정보는 서버에 저장하고 클라이언트 식별자인 JSESIONID을 쿠키에 담는다
• 클라이언트는 서버에 요청을 보낼 때 JESSIONID 쿠키를 함께 보낸다
• 서버는 JESSIONID 유효성을 판별한다.

JWT 기반 인증

• JWT 토큰을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.

  • Header : 알고리즘 및 토큰 타입을 지정
  • Payload : 클라이언트의 고유 ID값 및 유효기간 등을 포함
  • Signature : Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성(비밀키가 유출되지 않는 한 복호화가 불가능하고 토큰의 위변조 여부를 확인하는데 사용된다)

• 로그인 요청이 들어오면 검증 후 클라이언트 고유 ID등의 정보를 Payload에 담는다.

• 비밀키를 사용해 JWT를 발급한다.

• 클라이언트는 전달받은 토큰을 저장하고 서버에 요청할 때마다 토큰을 요청헤더에 포함시켜 함께 전달한다.

• 서버는 비밀키로 복호화한 후 위변조 여부 유효 기간등을 확인한다.

  ---

  OAuth 2.0

• OAuth란?
  OAuth는 인터넷 사용자가 비밀번호를 제공하지 않고 다른 웹사이트에 대한 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다.
  사용자 입장에서도 신뢰되지 않는 사이트에게 자신의 비밀번호를 제공하지 않아도 되고 서버를 운영하는 개발자 입장에서도 사용자의 비밀번호가 노출되는 일을 사전에 방지할 수 있다.
  

• Oauth 용어 정리

  • Resource Owner : 자원의 소유자
  • Client : Resource Server에 접속해 자원을 가져오려는 클라이언트(웹 어플리케이션)
  • Resource Server : Client가 제어하려는 자원을 보유하고 있는 서버(google, facebook)

• 등록
  Client는 Resource Server가 제공하는 방식으로 Client_id와 Client_Secret, Redirect URI를 발급받습니다.
  

• Resource Owner 인증
  Client는 Resource Owner로부터 인증을 받아야한다.

  • Resource Owner가 Resource Server의 자원이 필요한 Client의 서비스에 접근하려고 한다.
  • Client는 Resource Owner에게 로그인 화면과 같은 다음과 같은 주소의 OAuth를 제시한다.

    https://source.server/?client_id=1&scope=B,C&redirect_uri=https://client/callback/

  • Resource Owner가 OAuth를 통해 Resource Server에 로그인을 한다.
  • 로그인을 확인한 Resource Server는 client_id와 redirect_uri를 확인하고 접근 권한 허용할지 Resource Owner에게 물어본다.
  • Resource Owner가 동의를 하면 Resource Server는 아래 항목을 수집하고 Authrization code를 생성한다.

    scope: B,C
    // 수집
    Authrization code : 3
    // 생성

• Resource Server 인증
  Client는 다음으로 Resource Server로부터 인증을 받아야 한다.

  • Resource Server는 Resource Owner에게 Client의 redirect_uri로 이동하라는 명령을 내립니다.

    Location:https://client/callback?code=3
    // Authrazaition code가 포함된 정보를 담아 보냅니다.

  • 명령받은 Resource Owner은 Client에게 Authrization code를 전달한다.

  • 마지막으로 Client는 ACCESS TOKEN을 받기 위해 다음과 같은 형식으로 Resource Server에게 요청합니다.

    https://resource/token?grant_type=authrization_code&code=3&redirect_uri=https://client/callback&client_id=1&client_secret=2
    // authrization_code, redirect_uri, client_id, client_secret정보를 담아 보냅니다.

  • 해당 정보를 받은 Resource Server는 판단하여 ACCESS TOKEN을 부여한다.

• ACCESS TOKEN

  • Resource Server는 Client에게 ACCESS TOKEN을 부여한다.
  • 해당 ACCESS TOKEN에는 Client가 user_id로 위임 받은 scope에 대한 Resource Server 자원을 이용할 수 있게 된다.

• 추가 정보

  • 해당 API를 사용하기 위해서는 OAuth 제공 사이트에서 제공하는 형식을 따른다 대부분 Header에 curl H - Auhorization : bearer <access_token>과 같은 형식으로 보낸다 한다. 이 부분에 대해서는 문서를 확인하자.
  • refresh token의 경우 ACCESS TOKEN을 부여하면서 함께 부여되는 경우가 많고, 아래와 같은 형식으로 전송할 경우 ACCESS TOKEN을 갱신해준다.
    자세한 내용은 OAuth 2.0 rfc(표준)을 찾아보자.

    client_id = <      >&
    client_secret = <    >&
    refresh_token = <      >&
    grant_type = refresh_token

참조

https://opentutorials.org/course/3405
https://datatracker.ietf.org/doc/html/rfc6749