[OAuth2.0] 서버 사이드 워크플로우

---

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

0. 서버 사이드 워크플로우란?

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

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

1. Access Token

마찬가지로 서버 사이드 워크플로우도 최종적으로는 Access Token을 사용해 사용자의 리소스에 접근합니다. 하지만, 이전 클라이언트 사이드 워크플로우와 다르게 토큰을 발급받기 위해선 한 단계를 더 거쳐야합니다.

서버 사이드 워크플로우는 리소스 제공자에게 먼저 연락처에 접근할 수 있는 태그를 획득하고, 획득한 태그를 다시 리소스 제공자에게 보여준뒤 엑세스 토큰을 획득하게 됩니다. 최종적으로 획득한 엑세스 토큰을 이용해 사용자의 연락처 정보에 접근할 수 있습니다. 여기서 태그는 'Authorization Code'를 의미합니다.

여기서 중요한 점은 엑세스 토큰을 받을 때 사용하는 태그는 한번만 사용할 수 있다는 것입니다. 태그는 일단 한 번 사용된 이후에는 또 다른 엑세스 토큰을 얻기 위해 재사용 될 수 없습니다.

클라이언트 사이드 워크플로우와 중요한 차이점은, 엑세스 토큰이 브라우저에게 절대 전달이 되지않는다는 것입니다. 즉, Velog 서버와 Google 서버간에 엑세스 토큰이 직접 교환되기 때문에 엑세스 토큰은 브라우저 애플리케이션으로 전달되지 않습니다. 따라서 엑세스 토큰이 유출되거나 중간에 탈취될 위험성이 줄어들게됩니다. 😅

2. 장점 vs 단점

서버 사이드 워크플로우는 많은 장점과 단점을 가집니다.

✔ 장점

• 보안성 : 엑세스 토큰이 서버간에 교환됨으로 키가 탈취될 가능성이 줄어듭니다.
• 장기간 접근 가능 : 클라이언트가 정보를 안전하게 저장할 수 있으므로 사용자의 데이터에 접근하기 위한 엑세스 토큰을 저장해 장기간 사용할 수 있습니다.

✔ 단점

• 복잡성 : 클라이언트 사이드 워크플로우보다 좀더 복잡한 구현방법이 필요합니다.

다음 글에서는 전체적인 OAuth2.0의 흐름을 자세히 살펴보도록 하겠습니다.

---

참고자료

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

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

---