🥐 개요
이번 글은 Outlook add-in에서 OpenID Connect(OIDC)를 이용한 소셜 로그인 구현 방법을 다루려고 한다.
사실 '나만 보는? Outlook Add-in 시리즈'를 시작한 이유이기도 한 이번 글은 개발 환경 때문에 삽질은 가장 많이 한 부분이었다.
혹시, 다른 누군가가 (진짜 없을 거 같지만) Outlook Add-in을 개발하여 같은 상황을 겪게 됐을 때 삽질을 덜 했으면 하는 마음에 작성하게 되었다.
글 순서는 Outlook의 Web 버전과 Desktop App의 환경 차이를 설명하고, Google, Facebook 등 소셜 로그인을 시도할 때 기존의 라이브러리를 이용하지 못하는 이유를 설명한다.
그다음 office 제공 함수(dialog)를 사용해서 소셜 로그인을 구현하는 방법과 세션 유지를 위한 google id_token의 갱신 방법을 마지막으로 설명할 예정이다.
이 부분은 분량 조절 실패로 다음 게시물에서 작성한다.
🍕 Outlook Web과 Desktop App 환경 비교하기
Outlook Add-in은 Web뿐만 아니라 모바일 App이나 Desktop App으로도 사용이 가능하지만, 이번 글은 Web과 Desktop App 환경을 대상으로 작성하였습니다.
Web과 Desktop App 환경에서는 Outlook Add-in은 같은 React 코드로 동작이 가능합니다. 하지만 Desktop App의 경우 Electron으로 개발되었기 때문에 사용할 수 있는 자원 (resource)에서 Web과 차이점이 있습니다.
첫 번째 차이점은 외부 Web browser와 데이터를 주고받을 때 발생합니다.
Web의 경우 일반 웹 사이트와 동일하게 거의 모든 기능을 사용할 수 있으며, 새로운 Web browser 창을 열고 데이터를 주고받는 것이 가능하지만,
Desktop App의 경우 Outlook 내 Add-in 프로그램과 사용자 개인의 외부 browser와 데이터 통신이 불가능하며 Electron App 내에서 제공하는 방법을 이용해서 데이터를 주고받아야 합니다.
(Office 제공 함수인 Office.context.ui.displayDialogAsync 사용, 하단에 추가 설명)
두 번째 차이점은 때문에 Web 저장소 (Cookie, Local Storage 등)에 있습니다.
우선 Web과 Desktop App 모두 cookie와 localstorage 모두 사용이 가능합니다. 하지만 Desktop App의 경우 API 등을 통해 set cookie는 자유롭게 가능하지만, outlook 자체 앱이나 add-in 앱이 재시작이 될 때 outlook과 같은 도메인 (ex. outlook.office. ~~ )으로 시작되지 않는 쿠키들은 삭제가 되는 문제를 가지고 있습니다.
그렇기에 서버에서 내려주는 데이터(ex. 세션 유지를 위한 데이터 등)들은 쿠키가 아닌 localstorage에 저장이 필요합니다.
- 번외 1
클라이언트 환경에서 백엔드에게 API 요청 시에도 신경을 써야 합니다.
기존에 구현된 통신 방식은 클라이언트는 Web Server에 API를 요청하고 Web Server는 사용자가 보낸 data와 Cookie 속 데이터를 수집하여 백엔드 서버에 요청하는 방식으로 구현되어 있었습니다.
하지만, Outlook의 경우에는 Cookie 사용이 불가능했기에 클라이언트 환경에서 새로운 outlook 용 헤더 필드를 삽입하고 웹 서버에서 헤더 필드 안 데이터를 웹 서버용 쿠키에 저장하는 과정을 거쳐서 백엔드로 보내는 방식으로 변경하여 해결했습니다.
- 번외 2
여기까지 글을 읽고, '그럼 Web에서는 Cookie를 이용하고 Desktop App 환경에서만 localstorage를 사용하도록만 바꾸면 되는 거 아니야?'라고 생각할 수도 있다.
하.지.만. 그렇게 생각한 당신,,, 제2의 IE라 불리는 safari를 잊었다.
safari에선 도메인과 다른 쿠키 사용을 제한하기 때문에 결국 localstorage을 사용하는 것으로 전체 로직을 변경하였다.
🍔 Google, Facebook 등 소셜로그인을 시도할때 라이브러리를 이용하지 못하는 이유
사실, 서비스에 Google, Facebook 같은 소셜 로그인을 추가하는 작업은 그리 어려운 작업이 아니다.
인터넷이 다른 사람들이 올린 예제도 많고, gapi나 react-google-login을 이용해 손쉽게 구현이 가능하기 때문이다.
하지만 Outlook에선 조금 까다롭다. 🥲
Outlook Web 환경에선 앞서 언급한 라이브러리를 이용하여 간단히 구현이 가능하지만, Desktop App 환경에선 위에서 '🍕 Outlook Web과 Desktop App 환경 비교하기' 부분에서 설명한 내용과, Outlook Add-in 안에서 자체 서비스의 URL 이동을 시도할 때 현재 유저의 도메인과 이동하려는 URL의 도메인이 아니면 같지 않으면 이동을 허용하지 않는 문제가 있기 때문이다.
그렇기에 Outlook에선 Office 제공 함수와 Redirect URI을 이용하는 방식으로 구현해야 한다.
(자세한 방법은 다음 시리즈에 계속...)
🥞 마치며
오랜만에 글을 쓰면서 '이번 글엔 소셜 로그인까지 끝내야지' 하고 다짐했지만...
자세히 쓰다 보니 역시나 분량 문제로 끝내지 못했다.
하지만 원래 시리즈 글은 길어야 있어보이는법!!
계속..
