OAuth 2.0 이란

이번에 스프링으로 제작하는 프로젝트에서는 구글 로그인을 사용해보려 했습니다.

요즘들어 구글, 카카오, 트위터 등 외부 애플리케이션 계정을 통해

로그인이 가능하도록 하는 곳이 많아졌어요.

혼자 대충 독학해보려했는데, 생각보다 복잡하고 개념부터 알아가야할 것 같아

https://www.inflearn.com/course/web2-oauth2

[무료] Web2 - OAuth 2.0 - 인프런 | 강의

해당 강의를 시청하는 중입니다.

---

우선 OAuth가 사용되는 이유부터 알아봤습니다.

내 앱 사용자의 다른 앱에서의 데이터를 사용하고 싶을 때 기존 방식으로는,

다른 앱의 아이디, 패스워드 등의 정보를 사용자에게 직접 받았어야 합니다.

즉, 사용자의 구글 데이터를 이용하고 싶으면 그 사용자의 구글 아이디,  패스워드를 요청해야했습니다.

 

하지만, 우리의 앱이 신뢰할 수 있는 환경도 아닐뿐더러 직접 개인정보를 주고받는 행위는 안전하지 못합니다.

OAuth가 여기서 등장합니다.

 

OAuth는 외부 서비스에게 사용자의 계정 정보를 직접 보내지 않고, 개별의 AccessToken을 통해 접근할 수 있도록 합니다.

직접 아이디, 패스워드를 저장하고 있지 않다는점과, 외부서비스의 모든 기능을 요구하는게 아닌

내 앱 서비스에서 필요한 기능만 외부 서비스에서 가져올 수 있다는 점이 OAuth의 장점입니다.

 

OAuth에서는 사용자, 내 서비스, 외부 서비스의 명칭이 달라집니다.

외부 서비스는 내 서비스에서 필요한 데이터를 전달해주기 때문에, Resource Server로 불리고,

사용자는 그 데이터의 당사자이기 때문에 Resource Owner,

그리고 내 서비스는 데이터를 사용하고 싶어하는 측이기 때문에 Client 로 불립니다.

---

OAuth를 사용하기 위해선, Client에서 Resorce Server로부터 미리 등록을 받아놓아야 합니다.

서비스마다 다르지만, 보통 Cleint ID와 Client Secret, Authorized redirect URls는 공통적으로 필요합니다.

Client id와 Secret은 우리 서비스임을 Resource Server에게 명시합니다.

redirects url은 Resouce Server에게 입력한 주소외에는 허용하지 않도록 미리 알려주는 주소입니다.

 

그리고, 우리의 서비스가 실제로 Resource Server에게 사용자 데이터를 받아 사용하고싶다면,

먼저 Resource Owner(사용자)에게 승인을 받아야 합니다.

이는

구글 로그인

과 같은 버튼을 의미합니다.

저 버튼의 URL을 살펴보면 다음과 같은 형식입니다.

https://resource.server?client_id=1&scope=B,C&redirect_uri=client/callback

client id는 우리 서비스임을 Resource Server에게 알리고, scope는 Resource Server의 어떤 기능을 이용하고 싶은지를

명시합니다.

redirect_url은 후에 우리 서비스가 Resource Server에게 어떤 url로 요청할 것인지를 암시합니다.

저 버튼을 누르면,

권한 요청

Resource Owner의 정보 사용 권한을 수락을 요청하게됩니다.

수락한다면, Resource Server는 어떤 사용자가 어떤 url을 통해, 어떤 scope를 요청하는지를 저장합니다.

---

이 때, Resource Server는 Resource Owner에게 authorization code라는 것을 전달합니다.

이는 임시 비밀번호의 역할을 합니다.

Resource Owner는 다시금 Client에게 발급받은 임시 비밀번호(authorization code)를 전달합니다.

 

이제 AccessToken을 발급받기전 마지막 단계인데,

Client가 Resource Server에게 AccessToken을 요청합니다.

authorization code와 redirect_url, client_id, client_secret을 Resource Server에게 제공해야합니다.

 

Resource Server는 모든 정보가 일치함을 확인하고, Resource Server는 이미 인증을 마친 Client의 authorization code를 삭제합니다.

그 후, AccessToken을 발급합니다.

 

여기까지가 Resource Server, Resource Owner, Client간 AccessToken을 발급받는 과정이었는데,

생각보다 복잡한 과정인 것 같습니다.

이 이후로는 Resource Server에게 API를 요청하는 과정을 공부합니다.