[OAuth2.0] 클라이언트 사이드 워크플로우

---

이번 글에서는 비신뢰 클라이언트가 사용하는 OAuth2.0 정보교환 방법인 클라이언트 사이드 워크플로우에 대해 알아보겠습니다.

0. 클라이언트 사이드 워크플로우란?

앞선 글에서 클라이언트 사이드 워크플로우는 비신뢰 클라이언트가 사용하는 정보교환 방식임을 확인 할 수 있었습니다.

이번 글에서는 마찬가지로 Velog에서 구글 아이디로 회원가입을 한다고 가정하도록 하겠습니다. 빨간색 부분이 이번 글에서 다룰 부분입니다.

1. Access Token

클라이언트 사이드 워크플로우를 사용하는 어플리케이션은 비 신뢰 어플리케이션이므로 기밀 정보를 저장하고 전달하는 것을 신뢰할 수 없습니다.

클라이언트 사이드 워크플로우에서 아래 빨간색부분 즉 권한을 받는 부분에서 서비스 어플리케이션(Velog)은 리소스 제공자(Google)로 부터 🔑를 받게 되는데 이를 OAuth2.0에서는 'Access Token'이라 합니다.

이 Access Token을 리소스 제공자에게 보여주면 리소스 제공자는 해당 서비스가 권한을 부여받았다는 것을 확인할 수 있습니다. 이러한 Access Token은 특정 문만 열 수 있는 키라고 생각하면 됩니다. 예를 들어 Velog는 사용자 프로필정보를 확인할 수 있는 Access Token만 부여받았으므로, 사용자의 다른 정보에는 접근을 할 수 없습니다.

이러한 Access Token에는 bearer 토큰이 가장 많이 사용됩니다.

bearer 토큰은 토큰만 가지고 있으면 더이상 필요한 것이 없다는 의미에서 그 이름이 붙여졌습니다. 즉 특정 리소스에 접근하기 위해 토큰 외에 다른 것은 필요 없고, 단지 토큰만 가지고 있으면 됩니다. 위의 예시에서 bearer 토큰을 가지고 있는 사람이면 누구나 아무런 제약 없이 특정 사용자의 유저 정보에 접근할 수 있다는 의미입니다.

✔ 이러한 토큰을 요청하는 과정은 사용자 대신 애플리케이션이 사용자의 보호된 리소스에 접근하길 원하거나 접근해야 될 때마다 반복됩니다.

2. 장점 vs 단점

클라이언트 사이드 워크플로우는 많은 장점과 단점을 가집니다.

✔ 장점

• 단순함 : 구현이 매우 단순하며, 모든 동작이 웹 브라우저에서 일어나므로 백엔드 서버나 데이터 저장이 필요하지 않습니다.

✔ 단점

• 보안성이 낮다 : 엑세스 토큰이 오픈된 브라우저로 전달되므로 탈취될 가능성이 존재합니다.
• 단기간 접근만 가능 : 오랜 기간 키를 저장 할 수 없으므로 사용자는 반복된 인증을 통해 토큰을 재발급 받아야합니다.

위와 같이 보안적인 단점때문에 비신뢰 클라이언트를 개발하는 개발자는 해당 어플리케이션에서 읽기 전용의 리소스에만 접근을 제한하는 것이 좋습니다. 이렇게하면 토큰이 탈취되더라도 피해를 최소화 할 수 있습니다.

다음글에서는 서버 사이드 워크플로우에 대해 알아보겠습니다.

---

참고자료

OAuth 2.0 마스터:OAuth 2.0 애플리케이션 개발을 위한 모든 것

파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음

---