오늘은 지난 시간까지 실행했던 변화를
직접 확인해보도록 하겠습니다
이전과 동일하게, SpringBoot 웹 애플리케이션을
디버그 모드에서 시작할 것이고 이는 웹 애플리케이션을
기본 포트 8080로 설정할 것입니다
엔드 유저로서
Spring Boot 웹 애플리케이션 내에 있는
고정된 API에 접속해보고
어떤 일이 생기는지 살펴보겠습니다
저는 브라우저에 들어왔고, 고정된 API에
접속을 시도해보겠습니다. 고정된 API는 local host 8080/입니다
이게 여러분이 접속을 시도할 수 있는 URL 입니다
제가 enter을 클릭하자마자
제 Spring Boot 클라이언트 애플리케이션이 저를
GitHub 로그인 페이지로 이동시킨 것을 볼 수 있습니다
이것이 제가 구성한 클라이언트 ID고
여기서 제 GitHub auth 서버를 볼 수 있습니다
제 로고 그리고 애플리케이션 이름인
"GitHub에 가입하시고 EazyBytes를 유지하세요"가 보입니다
제 실제 GitHub 인증서를 요구하고 있기 때문에
사용자 이름 즉, EazyBytes를 입력하고
비밀번호도 입력해야 합니다
완료하고 나선, 로그인하기 버튼을 눌러야 합니다
인증이 성공적으로 끝나면
GitHub가 제 승인을 요구하는 것을 볼 수 있습니다
당신의 개인 데이터를 EazyBytes로 공유하는 것을 허가합니까?
제 개인 데이터를 보여주고 있습니다
EazyBytes에게만 공유될 프로필 정보가
읽기 모드로 보여집니다
중요한 메모가 써져있는데요
이 애플리케이션은
사용자의 개인적인 프로필 정보에 접속할 수 있으며
인증 이후로 다음과 같은 URL로 안내될 것이라는
안내문도 명시되어 있습니다
만약 제 엔드 유저가 이 정보에 동의한다면
'Authorize EazyBytes' 버튼을 누르겠죠
그리고 나면 제 안심 경로인 '/'로
다시 안내될 것입니다
여기에 중단점을 두었기 때문에
실행을 멈추게 된 것입니다
여러분이 이 토큰 대상 안에
무엇이 있는지 살펴보신다면
엔드 유저에 대한 모든 개인 데이터가 있는 걸 알 수 있습니다
예를 들어 계정 ID가 무엇인지
소비자가 GitHub auth 서버 내에서
어떤 권한을 허가했는지 등을 알 수 있습니다
화면을 보면 ROLE_USER 권한과
read:user 권한도 가지고 있습니다
그리고 유저 속성으로 이동하면
이것은 로그인 할 때 유저명입니다
또, 계정의 ID를 알 수 있습니다
비슷하게, 아바타 URL이 있습니다
이것을 사용하면 최종 소비자의 프로필 사진을 볼 수 있습니다
팔로워 URL도 존재합니다
이것을 사용하면
제게 몇 명의 팔로워가 있는지 누구나 알 수 있습니다
따라서 많은 정보들을 파악할 수 있는데
예를 들어 공개 게시물이 몇 개 있는지
혹은 비공개 게시물이 몇 개 있는지 등을 파악할 수 있는 것입니다
보시다시피 이것이 제 GitHub 계정용
이메일 계정입니다
그리고 제 상태 메세지도 있습니다
이 문장이 제 GitHub 프로필에 써져 있는
상태 메세지입니다
따라서, 우리가 auth 서버로부터 제공받은
모든 정보들이
엔드 유저, 리소스 소유자에게서
클라이언트 애플리케이션 즉, Spring Boot 애플리케이션에
공유해도 좋다는 허가를
받았기 때문에 허용될 수 있는 것입니다
자 이제 제가 이 중단점를 제거한다면
사용자는 이 secure.html로 안내될 것입니다
여러분들이 이 창에 들어가보면 확인할 수 있듯이 말이죠
보시다시피 "successfully logged in using GitHub
and OAUTH2"라고 적혀있습니다
여기까지 설명했으니, 지금까지 한 것에 대해
여러분이 이해를 하셨을 것이라고 생각합니다
하지만 이것은 그저 social logins와 같은 방법으로
auth 서버에 영향을 미칠 예시일 뿐입니다
GitHub, Facebook, Google, Twitter와 같은 모든
유명한 단체들은 social login이라는
명칭이라고 부르죠
하지만 이러한 소셜 로그인을
저희 기업의 웹 애플리케이션에 사용할 수 있을까요?
당연히 불가능합니다
이러한 social login은 더 작은 애플리케이션들이나
블로그 혹은 통계 웹사이트에만 적용됩니다
실제로는, 별도의 제대로 된 리소스 서버가 존재할 것입니다
제대로 된 auth 서버도 별도로 존재하겠죠
이들은 클라이언트 애플리케이션과 리소스 소유자를 구분할 것입니다
실제 애플리케이션의 경우에는
이 모든 역할들이 독립적으로 존재합니다
그리고 지금 저희가 진행했던 실행 방법은
실제 애플리케이션에게는 부족할 수 있습니다
그리고 소셜 로그인의 경우에
또 다른 단점이 존재합니다
자기 자신의 역할과 권한을 직접 구성할 수 없다는 점입니다
GitHub의 auth 서버에서
자신만의 유저를 설정할 수도 없죠
그 이유는 당신의 단체에 속하지 않기 때문입니다
따라서, 만약 OAUTH2 플로우에 대한 완전한 통제를 원한다면
본인의 단체에 본인만의 승인 서버를
소유하고 있어야 합니다
그리고 그 승인 서버 내에서는
무엇이든 자유롭게 실행할 수 있는 것이죠
본인만의 역할이나 승인을 제작할 수도 있고요
이것이 우리가 본인만의 auth 서버를 설정하는 과정에서
선택지를 잘 둘러봐야 하는 이유입니다
시장 내에서 활용할 수 있는
유명한 제품들의 도움을 얻어 둘러볼 수 있죠
이 부분은 다음 강의에서부터 다시 시작하도록 하겠습니다
오늘 설명한 내용이 모두 명확하게 이해가 가셨길 바랍니다
감사하고, 다음 강의에서 뵙겠습니다
수고하셨습니다