OIDC 소셜로그인 프론트, 백엔드 동작 과정

REST API
1

OIDC를 이용해서 웹 서비스를 구현할 예정입니다.
아래 링크는 OIDC가 아닌 임시code를 이용하여 토큰을 발급 받고 이를 Resource Server에 요청하는 시나리오이지만 프론트 또는 백엔드 중 하나에만 책임을 맡아서 구현을 하는 내용입니다.

https://www.devyummi.com/page?id=66934f448a005e7d8f32213a

저는 OIDC를 이용할때도 아래 사진을 보면 백엔드가 모든 책임을 맡는다고 생각합니다. Spring의 OAuth 2.0 Client 라이브러리를 사용하지 않고 직접 구현을한다면 아래의 과정처럼 생각했습니다.

  1. Step1에서 Rest API를 이용하여 프론트에서 백엔드를 호출하여 백엔드가 Get /oauth2/authorize 엔드포인트를 호출하여 백엔드로 리다이렉션을 통해 임시코드를 받아 프론트에 임시코드를 전송
  2. 프론트에서 임시코드를 파라미터로 백엔드에 전송하여 백엔드에서는 Post /oauth/token을 호출 후 토큰 발급

임시코드는 노출되어도 상관이 없는 지와 OIDC를 이용한 소셜로그인을 할 때 프론트와 백엔드의 동작과정이 궁금합니다.

2

임시코드는 인가 코드를 말씀하신걸까요?

3

네 맞습니다. 몇몇 프로젝트 보니 인가 코드와 리다이렉 url을 프론트에서 받고 이를 백엔드에 전송 후 백엔드에서 토큰을 발급하는데 왜 그렇게 하는 지 모르겠습니다. 권장사항에서는 백엔드에서 모두 처리하는걸로 아는데

4

앞선 다른 분들의 문의들을 보니
백엔드 리다이렉트 URI에서 다시 프론트로 리다이렉트 하지 않고
프론트 리다이렉트 URI에서 인가코드를
자체 개발한 백엔드에 비동기 통신 방식으로 호출 하려고 그렇게 하시는듯 하네요.

백엔드에 일임하도록 하는 것은 보안상 발생할 수 있는 문제를 최소화하기 위함이나,
추가 고객정보 입력 받아 가입하는 등. 서비스 상황에 따라 민감정보가 반드시 프론트와 교신해야하는 경우도 있으니 암호화, https통신, 인가코드가 탈취되어도 액세스 토큰 발급 할 수 없도록 허용 IP 주소 등록, PKCE 와 같이 적절한 보완책만 있으면 됩니다.