OAuth 2.0은 무엇이고 어떻게 적용할 수 있을까?

OAuth 2.0

Open Standard for Authorization

2006년 Twitter와 Google이 정의한 개방형 Authorization 표준

 

요즘 웹, 모바일 서비스를 이용하다보면 ~~로 로그인하기로 불리는 소셜로그인을 자주 찾아볼 수 있다.

이게 OAuth이다.

 

작은 서비스에서는 사용자의 정보를 안전하게 저장하고 관리하는 것은 큰 부담이다. 이 부담을 다른 큰 플랫폼(구글, 페이스북, 네이버 등)에 위임하여 이용할 수 있다. OAuth는 이 위임 과정을 위한 규약이다.

2.0 버전은 1.0 버전에서 발생된 보안 문제를 개선한 버전으로,

1.0 버전에서는 프로토콜로 2.0으로 업그레이드 되면서 프레임워크로 정의되고 있다.

표준 문서 (RFC6749) : https://datatracker.ietf.org/doc/html/rfc6749

  +--------+                               +---------------+
    |        |--(A)- Authorization Request ->|   Resource    |
  |        |                               |     Owner     |
  |        |<-(B)-- Authorization Grant ---|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(C)-- Authorization Grant -->| Authorization |
  | Client |                               |     Server    |
  |        |<-(D)----- Access Token -------|               |
  |        |                               +---------------+
  |        |
  |        |                               +---------------+
  |        |--(E)----- Access Token ------>|    Resource   |
  |        |                               |     Server    |
  |        |<-(F)--- Protected Resource ---|               |
  +--------+                               +---------------+

용어

1. Resource Owner, 자원 소유자구글 로그인을 통해서 구글의 유저 정보를 가져오는 상황이라면 그 구글 유저 자원에 대한 소유자로 이해할 수 있다.
2. 우리 서비스의 사용자를 말한다.
3. Client, 클라이언트내가 개발하고 있는 서비스가 클라이언트가 된다. (내가 개발하고 있는 서버가 클라이언트가 된다..!!!)
4. 구글입장에서의 클라이언트라고 생각하면 편할 것 같다.
5. OAuth 2.0을 통해서 타사 서비스의 자원을 이용하고자하는 주체를 말한다.
6. Authorization Server, 인가 서버클라이언트에 ID, Secret을 부여하고, Code를 발급하거나 Token을 발급한다.
7. 인가 처리를 담당하는 서버이다.
8. Resource Server, 자원 서버클라이언트는 인가서버에서 발급받은 토큰으로 자원 서버에 접근해서 원하는 자원을 이용할 수 있다.
9. 클라이언트에서 사용하고자 하는 자원(여기서는 유저 정보)를 가지고있는 서버이다.

적용한 매커니즘

(서버와 클라이언트가 헷갈릴 수 있어 프론트엔드, 백엔드 용어로 작성했습니다.)

OAuth를 공부하며 찾아본 글들 중 인증, 인가처리를 프론트엔드에서 하고 있는 경우를 종종 찾아볼 수 있었다.

하지만 프론트엔드에서 이것들을 처리하게 되면 여러 문제가 있다.

1. Client ID를 공개해야한다.OAuth 인가서버에 요청을 보낼 때 Client ID를 함께 보낸다.리다이렉션을 하게 되면 url을 통해 공개가 되지만, 코드에 남게하고 싶지 않았다.
2. 프론트엔드에서 인증, 인가를 처리하려면 Client ID를 공개해야 한다.
3. 이것은 문제라기 보다는 개인적으로 이렇게 하고 싶지않았다.
4. 발급받은 액세스 토큰이 노출될 수 있다.그리고 발급받은 액세스토큰을 가지고 자원 서버에 필요한 자원을 요청받아 이용한다.
5. 이 과정을 백엔드에서 처리하게 되면 프론트엔드에서 알 수 있는 것은 자원서버에서 얻어온 정보뿐이지만, 프론트엔드에서 진행하게 되면 액세스토큰까지 알게 되어 OAuth 계정 정보 탈취의 위협이 생긴다.
6. 인증코드와 함께 응답을 받으면 인증코드와 Client Secret을 이용해 액세스 토큰을 발급받는다.

이런 이유들로 백엔드에서 모든 OAuth 과정을 진행하는 것이 옳다고 판단했고,

따라서 프론트에서 인증 인가과정에 신경쓸 것이 하나도 없게 만들자라는 목표를 가지고

다음과 같은 매커니즘으로 구현하였다.

 

프론트에서는 a 태그로 요청만 하나만 보낸다면 로그인이 완료되고, JWT토큰이 쿠키로 발급되어 이후 인증에도 신경쓸 것 없이 처리할 수 있게 했다.

Github Login 적용 모습

 

---

참고

https://hudi.blog/oauth-2.0/

 

이어지는 글
👉 refresh token 도입기