제가 제공하려고 하는 서비스는 Gmail 읽기 권한이 필요합니다. 그래서 Google OAuth 2.0을 통해 권한을 요청합니다. 어차피 구글 계정이 필요하다면, 그냥 구글 계정만을 이용해서 회원, 로그인 기능을 구현하는 게 낫겠다고 판단했습니다.
SSO가 어떤 플로우를 갖게 되는지 조금 이해가 되지 않았습니다.
권한 요청을 받게 돼서, access_token과 refresh_token을 받게 됐고, 그걸 활용하기 위해서 제 서버는 그걸 저장하긴 할텐데, 이후에 사용자가 다시 google 계정 로그인을 시도하게 될 경우에 또 권한을 승인해달라는 요청하는 페이지를 마주하게 되면 로그인에 질려버릴 것 같다는 생각이 들었습니다.
그건 OAuth 2.0을 요청하게 되는 제가 의도에 맞게 선택할 수 있었습니다.
prompt=none: 사용자 상호작용 없이 자동 진행 (이미 로그인된 경우만)
prompt=consent: 매번 권한 동의 화면 표시 강제
prompt=select_account: 계정 선택 화면 강제 표시또한 refresh_token을 받고 싶다면, access_type=offline을 설정하고 OAuth 2.0 권한 요청을 해야합니다.
access_type=offline은 사용자가 브라우저에 접속하지 않은 상태에서도 애플리케이션이 Google API에 접근할 수 있도록 하는 설정입니다. 사용자가 웹브라우저를 열어놓은 상태에서만 동작시킬 것이 아니기 때문에, 계속 애플리케이션이 API 접근할 수 있게 하기 위해서는 해당 설정이 필요합니다.
prompt=none, prompt=select_account로 설정한 경우, OAuth 2.0에서 권한 요청을 할 필요가 없다면 바로 원래 이용하려고 했던 웹서비스로 리다이렉트가 된다고 합니다. 다만, access_token과 refresh_token은 추가적인 권한 요청을 하지 않았기 때문에, 갱신할 수 있게 값을 새롭게 응답을 받지는 않습니다.
access_token의 유효기간은 1시간, refresh_token의 유효기간은 6달입니다. 다만, 정식 출시를 하지 않고 개발 단계인 경우에는 유효기간은 7일로 한정되는 것 같습니다.
고가용성 서비스를 위해서 access_token과 refresh_token이 끊기지 않고 계속 유효해야하는 경우에는 만료 기간을 알 수 있기 때문에, 며칠 안 남았을 때 적당히 알람을 제공하여 access_token과 refresh_token을 갱신 받을 수 있는 장치가 마련돼야 합니다.
