OAuth2.0의 표준 규격은 몇가지의 인증방식을 제공한다. 오늘은 하루종일 연결하려다가 결국 포기하고 말아버린 이야기를 해보려 한다.
Authorization code
Oauth2.0은 인증방식(grant type)에 따라 다른 흐름을 가진다. 흐름의 종류에 대해 궁금함다면 아래 북마크를 참고하자.
Authorization code는 그중 가장 기본적이고 많이 활용되는 방식이다. Auth 로그인을 한번정도 구현해봤다면 경험해봤을 것이다.
기본적인 흐름은 아래와 같다.
준비
1.
Clinet Id, Client Secret을 발급받음
2.
Redierct Uri를 등록함
흐름
1.
Resource Server에 인증 코드(code)를 요청한다
2.
Resource Server는 로그인 상태를 확인한다. 안되있다면 본인의 로그인 화면으로 연결하여 로그인을 진행한다.
3.
Resource Server는 client id, secret, 그리고 등록된 uri와 일치하는지 확인하고 code를 url에 담아 redirect uri로 보낸다.
4.
Client는 해당 코드를 가지고 Resource Server에게 token을 요청한다.
5.
Resouce Server는 다시 id, secert, uri,
code를 확인하고 token을 발급한다.
흐름은 크게 어렵지 않고 대부분의 프레임워크에는 해당 흐름을 자동화해둔 모듈이 존재한다. 실제로 SSR형태로 서비스를 만들었을 때 간단하게 구축하였었다.
삽질기
그래서 우습게 봤었다. 그러나 csr를 접목하고 서버와 프론트를 분리시키자 마자 끔찍한 문제가 발생했다. Cors. Cors가 궁금하다면 팔코에 잘 정리된 글이 있으니 한번 보자.
어디서 문제가 발생했냐면 42의 로그인 화면으로 클라이언트를 리다이렉트하려는 순간 발생했다. 서버 - 클라이언트간 cors는 설정되었다. 서버 - 42auth간 redirecr uri도 설정되었다. 42 - 클라이언트간 cors도 되었다. 문제는 서버에서 location을 42로 설정한 response를 302로 던질때 cors가 걸리는 것이었다. 문제상황에선 해당 uri로 클라이언트가 요청하는것에 에러를 발생시켰다. 근데 클라이언트에서 직접하는것은 된다는것이 문제였다. 이상하게도 한번 거치도 나면 cors설정들이 header에서 날아가버리는 것이었다.
강제로 헤더에 cors설정을 집어넣어도 봤고 아예 같은 host로도 날려보았지만 서버단 요청으로 해당 부분을 해결할 수는 없었다. 그나마 가능한것이 클라이언트단에서 cors를 심어 보내는 것이었는데 그렇게 할거였으면 서버를 나눌 이유가 없지...
결국 마지막으로 선택한것은 요청이 아니라 아예 서버로 redirect해서 login을 진행한 후 클라이언트로 다시 리다이렉트하는 형태로 구축하였다.
결론
해당 문제는 한번 쯤 고민해볼만한 문제라고 생각한다. 웹표준인 OAuth에서 클라이언트와 서버의 호스트가 완전리 분리되어있다면 이런 문제를 또 경험할테니까.
