스프링 소셜 로그인 흐름 관련하여 질문드립니다.

Question

위 두가지 그림을 보고 얼추 이해를 했습니다. 근데 제가 궁금한 것은왜 빨간 사각형 부분에서 authorization 서버에서 바로 access token을 return하지 않고authorization response -> access token request -> access token response라는 과정을 거치나요?왜 최초 로그인 시(회원가입) access token으로 Resource Server에 유저 정보를 요청하는 지는 알겠습니다.(첫 그림에도 나와있듯이 User Info를 받아서 내 DB에 저장하기 위해) 근데 첫 로그인이 아닌 경우에 파란 사각형에서는 왜 이후 로그인 시에도 굳이 유저 정보를 또 Resource Server에 요청하고, 이거를 내 DB와 대조하는 과정이 필요한가요? Authorization 서버에서 access token을 받은 순간 이미 해당 유저의 신원은 확인된 것이니 이걸 내 DB와 대조하고 내 토큰을 발급해주어도 되지 않나요?

BGProgramming · Accepted Answer

둘다 OAuth 소셜 로그인이라고 하셨지만.... 제 판단으로는 첫번째 그림은 구글 인증과 비슷하게 구성한 자체 서버 구조도라고 보입니다.일단 로직 자체가 조금 다릅니다.이유는 인증서버 및 리소스서버로 나오지 않고 두번째 그림처럼 구글서버가 되어야 합니다.그리고 구글 인증 서버에서 리턴하는 데이터가 첫번째로 리프레시 토큰이 수신될겁니다.즉, 리프레시 토큰을 API 서버에서 생성하지 않습니다.용어가 약간씩 달라 혼동이 올수 있기 때문에 먼저 용어가 정의를 들어가겠습니다.API서버는 자신의 서비스 API 서버로 정의하겠습니다.구글 인증 서버는 구글에서 자신의 회원을 인증하고 정보를 제공하는 서버로 정의하겠습니다.그러면 설명에 들어가겠습니다.일단 구글 로그인 및 회원가입은 크게 두가지로 보시면 됩니다.첫번째 그림과 유사한 Refresh 토큰 저장방식입니다. access_type&#61;offline 으로 요청하는 형식입니다.해당 옵션을 사용하는 경우는 사용자가 오프라인일 경우에도 구글에게 정보를 요청하여 수집하기 위함입니다.이는 어디에 사용할 수 있냐면 예를들어 사용자 유튜브 채널을 분석해 주는 서비스를 기획했다고 합시다.이 경우 매일마다 구독자수나 채널 조회수등을 수집하여 추이를 분석할수 있습니다.두번째는 일반 로그인이나 회원가입시 사용하는 방법으로 일회성으로 처리하는 방식입니다.이 경우 API서버는 구글 인증서버에게 JWT 토큰에 사용자 정보를 받습니다.리프레시 토큰이 언급되고 저장해야 하기에 로그인이 아니라 회원가입 로직으로 설명하겠습니다.첫번째 리프레시 토큰의 처리 동작은 다음과 같습니다.여기서 주의할 점은 클라이언트 화면 갱신을 위해서 구글 인증서버가 API 서버 API를 직접 호출하는 것이 아니라클라이언트에 데이터를 넘기고 클라이언트가 서버 URL을 호출하는 방식으로 진행합니다.해당 동작은 클라이언트가 로드하는 https://accounts.google.com/gsi/client와 같은 구글 라이브러리에서 동작합니다.이렇게 해야 로그인 후 화면 갱신이 이루어 질 수 있습니다.두번째 방식은 좀더 간단합니다.정보를 JWT 토큰으로 넘겨주고 해당 정보를 서버에서는 디코딩하여 확인하면 됩니다.답변하는데 그림 그리느라 시간이 한참 걸리네요.음... 올려주신 첫번째 그림에서는 리프레시 토큰 발급시 api 서버가 인증코드를 발급하는 로직까지 설명하고 있네요.이게 좀 일반적인 방식이라 제 설명에는 생략이 되었는데...이것까지 그림에 넣는다면 refresh 토큰 발급시에는 client가 초기에 구글로 바로 요청을 하는것이 아니라호출하는 구글 Auth URL을 API서버에 요청합니다.그리고 API 서버는 사용자 구분을 위해서 누가 요청했는지 식별하기 위한 인증 코드를 발급합니다.그리고 이 자신의 서비스에서 발급한 인증코드와 함께 구글에 호출할 URL을 동봉해서 보내면클라이언트는 해당 URL을 호출하여 제가 그려준 첫번째 그림에 진입합니다.그리고 해당 URL을 클라이언트는 그대로 호출하고, 구글 인증서버는 Refresh 토큰과 API 서버에서 발급한 넘겨주고,다시 클라이언트는 API 인증 코드 및 구글 데이터와 함께 서버로 데이터를 넘기고... 이런식으로 동작합니다.이는 처음에 언급한것처럼 서버의 경우 어느 사용자나 비선형적인 요청이 들어오기에 해당 사용자를 인식해서 처리하기 위함입니다.

호호아조씨 · Answer

1 보안 때문에 2 대조 안하면 로그인 한 유저가 내 db의 어떤 유저인지 어떻게 알 수 있죠?

BGProgramming · Answer

답변을 하려다가 제가 헷갈린것이... 첫번째는 자체 인증 서버 구조도가 맞나요?보니까 질문자 분도 헷갈려하시는것 같은데.. 두번째 파란 부분에서 그림 보면 리소스 서버가 아니라 구글 인증 API라고 적혀있습니다만...두번째 그림은 구글 인증 서버라서 자신의 리소스 서버와는 관계가 없지 않나요?

작달막 · Answer

저도 잘은 모르지만.. 아는대로 적어봅니다.authorization code == 인증서, AccessToken == 교환쿠폰 느낌으로 보면 되지 않을까 싶어요. authorization 서버를 통해 oauth에서 필요로 하는 개인정보(프로필 사진, 이름 등)를 가져올 것임을 사용자에게 승인받고, 승인 받은 데이터를 실제로 가져오는게 AccessToken을 통한 통신이라서요.이게 왜 나뉘어져 있냐고 물으시는거라면... 약관과 실제 데이터 제공을 위한 기능을 따로 관리하기 위한거 아닐까 싶네요..?Authorization 서버에서 받은 AccessToken을 자신의 서비스의 로그인에서 JWT로서 기능하게 하고 싶다는 말씀이신거 같은데, 그렇게된다면 본인의 A서비스가 아닌 다른 B 서비스에서의 oauth 플로우를 통해 얻은 AccessToken을 통해서도 로그인을 할 수 있겠네요. 실제로 그럴 사람이 있을진 모르겠지만... 이건 좀 문제가 되지 않을까 싶어요.그리고 유저정보를 요청하는 경우는 서비스에서 사용할 개인정보가 지속적으로 업데이트 되어야 한다는 점에서 필요할 거 같습니다. 예를 들자면, 구글의 프로필 사진을 사용 중인 상황인데 어떤 사용자가 구글 프로필 사진을 바꿨다면 해당 서비스에서도 바뀌어야 한다거나 하는 경우가 있지 않을까요?

manijang2. · Answer

바로 엑세스코드를 요청하면 보안에 취약합니다.그래서 중간에 임시코드(=인증코드)를 받고 엑세스코드를 받도록 2단계를 거쳐서 받는거에요.

스프링 소셜 로그인 흐름 관련하여 질문드립니다.

5개의 답변

Q&A 목록