해당 글은 코드스쿼드 2022 마스터즈 코스 "Java 웹 백엔드" 과정을 수강하면서 학습한 내용 등에 대한 회고 글입니다. :)
수강 회고
어제 같은 백엔드 팀원과 함께 늦은 시간까지 팀 프로젝트 작업을 진행하느라 나뿐만 아니라 팀원 역시 아침부터 피곤한 기색이 역력해 보였다. 어제 팀 프로젝트 작업을 하면서 기능 구현을 하다가 도메인 주도 개발(DDD) 관점에서 우리가 설계한 구조와 작성한 코드들을 검토해보면서 '이게 맞나, 저게 맞나' 등 구조에 대한 고민을 하게되었던 탓이었다. 늦은 시간까지 작업을 했지만 이러한 고민들로 인해 당초 목표했었던 기능 구현은 하지 못했다.
사실 그렇다고 해서 나와 팀원이 고민했었던 부분에 대해 완벽하게 해결된 것은 아니었다. 고민은 했지만 현재의 상황에서 '이상적인 구조'가 무엇일까 논의해보았지만 마땅한 해결책이 떠오르진 않았다. 결과론적으로만 따지면 시간만 많이 보내고 어떠한 해결책을 도출하지 못했기 때문에 '의미 없는 삽질'이라고도 볼 수 있겠지만, '그 과정에서' 어떻게 하면 더 나은 구조로 설계하고 만들 수 있을지에 대해 논의하고 고민했었던 경험들은 나중에 다른 애플리케이션을 개발함에 있어 도움이 될 것이라고 생각된다.
학습 회고
- 반찬 주문 서비스 웹 앱 구현 프로젝트
- 팀원들(백 엔드 2명, 프론트 엔드 2명)과 zoom 회의실에서 학습
OAuth 인증 방식에는 여러가지 방식이 있는데, 대표적으로 인증 코드(Authorization Code)를 이용한 방식이 있는데, 각 과정들에 대해 아래와 같이 간단히 정리해보았다.
OAuth 2.0 (인증 코드를 이용한 방식) Flow
1. Resource Owner -> Client
이 단계에서는 예를 들어 Resource Owner(여기서는 '웹 브라우저')가 Client(여기서는 '서비스를 제공하는 웹 서버')에 접속하여 특정 서비스를 이용하는 중 Client가 제 3자 서버로부터 웹 브라우저를 이용하는 해당 Resource Owner의 리소스를 이용해야하는 상황(ex. 페이스북 글 게시, 구글 캘린더 날짜 기록 등)이 발생했다고 가정해본다.
2. Client -> Resource Owner
이때 Client가 제 3자 서버로부터 Resource Owner의 리소스를 대신하여 이용하기 위해서는 '사용자의 동의를 구하는 과정'이 필요하다. 이를 위해서 웹 서버는 사용자에게 제 3자 서버의 Authorization Server(인증 서버)에 대한 주소와 client_id, scope, redirect_uri 등이 쿼리 스트링으로 담긴 링크를 포함하고 있는 특정 화면을 보여준다.
3. Resource Owner -> Authorization Server
Resource Owner는 Authorization Server에 접속하여 인증(로그인) 작업을 수행한다. 이후 Authorization Server는 Resource Owner가 전송할 때 담긴 client_id와 redirect_uri 등을 확인하고 Resource Owner에게 어떤(앞선) Client가 특정 리소스를 제어해도 되는지 동의를 구한다.
4. Authorization Server -> Resource Owner
Resource Owner가 동의를 마치면 Authorization Server는 Resource Owner에게 'Authorization Grant(허가증)'와도 같은 인증 코드와 함께 앞선 redirect_uri 경로로 리다이렉트 요청을 보낸다. (ex. Location : https://client/callback?code=3)
5. Resource Owner -> Client
리다이렉트 요청에 의해 Resource Owner는 인증 코드와 함께 Client에 접속한다.
6. Client -> Authorizatione Server
Client는 Resource Owner가 전송한 인증 코드(Authorization Code)와 client_id 그리고 client secret을 제 3자 서버의 Authorization Server에 전송한다.
7. Authorization Server -> Client
Authorization Server가 전송받은 인증 코드와 client_id 그리고 client secret이 적합하다고 판단하면 비로소 Client에게 Access Token을 응답해준다.
8. Client -> Resource Server
Client는 앞서 Authorization Server로부터 받은 Access Token을 이용하여(ex. Authorization: Bearer <access token> 등) 제 3자 서버의 Resource Server에 특정 API를 호출할 수 있게 되고 이를 통해 Resource Owner를 대신하여 Resource Server 상의 리소스를 제어할 수 있게 된다.
학습 참고자료
- 유튜브 생활코딩 'OAuth 2.0'
- https://datatracker.ietf.org/doc/html/rfc6749
좋았던 점
- 이번 팀 프로젝트를 통해 OAuth의 개념과 흐름에 대해 명확하게 이해할 수 있었던 점이 큰 수확이었습니다. 👍
아쉬웠던 점
- 당초 목표했었던 부분까지 기능 구현을 하지 못한 점이 아쉬웠습니다. 💦
이전 보다 개선되었던 점
- 이번 프로젝트를 하면서 Nginx과 Spring boot를 다루어 보면서 이전 보다 웹에 대해 좀 더 잘 이해할 수 있게 되었습니다. ⭐