OAuth2

OAuth 2.0(Open Authorization 2.0, OAuth2)은 인증을 위한 개방형 표준 프로토콜입니다. 이것은 HTTP 서비스를 통해서 사용자 계정에 대한 제한된 엑세스를 얻을 수 있도록 어플리케이션에 허용하는 것입니다

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준이다. 

 

이 프로토콜에서는 Third-Party 프로그램에게 리소스 소유자를 대신하여 리소스 서버에서 제공하는 자원에 대한 접근 권한을 위임하는 방식을 제공합니다. 구글, 페이스북, 카카오, 네이버 등에서 제공하는 간편 로그인 기능도 OAuth2 프로토콜 기반의 사용자 인증 기능을 제공합니다.

 

OAuth2로 구성된 서버 인스턴스는 사용자 계정을 호스팅하는 서비스로부터 인증을 위임하며, 인증 프로세스를 직접 수행하지 않습니다.

OAuth 구성 요소

즉 서버로부터 앱이 토큰을 제공받는다는 것은 앱이 Client가 되는 것이고 서버가 Resource Server, Authorization Server가 되는 것

직접 사용자가 로그인 하는것이 아닌, 소셜 미디어로 로그인을 할 경우,

client(개인 서비스)는 Resource Owner(사용자)를 대신해 로그인 하는데, 이때 필요한 정보를 Resource Server(kakao, naver, ...)에서 얻어 서로 비교해 유효성을 판단한다.

client(개인 서비스)가 유저의 (로그인)정보/자원(resource)을 Resource Server에 요청해 대신 로그인을 하는 것이다.

 

이를 위해서 client는 다음 단계들을 가진다.

1. Resource Owner로 부터 동의(허용)
2. Resource Server로 부터 client 신원확인

왜 그래야 할까?
각각의 입장에서 생각해보자.

 

Resource Owner(유저) 입장

자신의 정보를 대신 사용하기 때문에 client(개인 서비스)가 어떤 정보를 활용하는지, 어떤 기능을 사용하려는지 모른다.

나쁜 마음을 가지면 개인정보를 마구잡이로 악용할수 있을 수도 있기 때문이다.
그러므로 client는 Resource Owner의 동의를 구해야 한다.

 

Resource Server(kakao) 입장

다른 사람의 일을 대신 해주는 사람이 정말 그 사람일지 궁금할 수 있다.
마찬가지로 Resource Owner의 일을 수행 해주는 client가 정말 그 client일까 하는 물음이 있다.

이런 의미에서 Resource Server는 Resource Owner의 브라우저를 통해 client를 구분하는 값(code)를 전달한다.

 

1. 사용자(Resource Owner)는 서비스(client)를 이용하기 위해 로그인 페이지에 접근한다.

2. 그럼 서비스(client)는 사용자(Resource Owner)에게 로그인 페이지를 제공하게 된다. 로그인 페이지에서 사용자는 "페이스북/구글 으로 로그인" 버튼을 누른다.

 

 

3. 만일 사용자가 Login with Facebook 버튼을 클릭하게 되면, 특정한 url이 페이스북 서버쪽으로 보내지게 된다.

 

브라우저 응답(reponse) 헤더를 확인하면 다음 url 내용을 확인할 수 있다.

 

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

 

이는, 사용자가 직접 페이스북으로 이동해서 로그인을 입력해야 하는데, 저 링크가 대신 로그인으로 이동 하게끔 도와준다

 

위에 코드가 어떻게 구성되어 있는지 알아보면

https://resource.server/? # 리소스 서버(네이버, 카카오 사이트 url)
client_id=1 # 어떤 client인지를 id를 통해 Resouce Owner에게 알려주는 부분
&scope=B,C # Resource Owner가 사용하려는 기능, 달리 말해 client가 자신 서비스에서 사용하려는 Resource Server 기능을 표현한 부분
&redirect_uri=https://client/callback # 개발자 홈페이지에 서비스 개발자가 입력한 응답 콜백.

향후 redirect_uri 경로를 통해서 Resource Server는 client에게 임시비밀번호인 Authorization code를 제공한다.

 

4. 클라이언트로부터 보낸 서비스 정보와, 리소스 로그인 서버에 등록된 서비스 정보를 비교한다.

 

4.1 확인이 완료되면, Resource Server로 부터 전용 로그인 페이지로 이동하여 사용자에게 보여준다.

 

5. ID/PW를 적어서 로그인을 하게되면, client가 사용하려는 기능(scope)에 대해 Resource Owner의 동의(승인)을 요청한다.

 

 

5.1  Resource Owner가 Allow 버튼을 누르면 Resource Owner가 권한을 위임했다는 승인이 Resource Server 에 전달된다. 

이로써 Resource Sever가 갖는 정보는 다음과 같다.

1. Client Id : Resource Owner와 연결된 client가 누군지
2. Client Secret: Resource Owner와 연결된 client의 비밀번호
3. Redirect URL : (진짜)client와 통신할 통로
4. user id : client와 연결된 Resource Owner의 id
5. scope : client가 Resource Owner 대신에 사용할 기능들

6  하지만, 이미 Owner가 Client에게 권한 승인을 했더라도 아직 Server가 허락하지 않았다. 따라서, Resource Server 도 Client에게 권한 승인을 하기위해 Authorization code를 Redirect URL을 통해 사용자에게 응답하고

 

7 다시 사용자는 그대로 Client에게 다시 보낸다.

 

이를 통해, client(서비스)는 Resource Server(페이스북)가 보낸 Authorization code, "code=3"를 Resource Owner(사용자)통해 받는다.

8. 이제 Client(서비스)가 Resource Server(페이스북)에게 직접 url(클라이언드 아이디, 비번, 인증코드 ..등)을 보낸다. 

 

9. 그럼 Resource Server는 Client가 전달한 정보들을 비교해서 일치한다면, Access Token을 발급한다. 그리고 이제 필요없어진 Authorization code는 지운다.

 

9. 그렇게 토큰을 받은 Client는 사용자에게 최종적으로 로그인이 완료되었다고 응답한다.

 

OAuth의 목적은 최종적으로 Access Token을 발급하는 것이다.

 

11 ~ 14. 이제 client(서비스)는 Resource server(페이스북)의 api를 요청해 Resource Owner(사용자)의 ID 혹은 프로필 정보를 사용할 수 있다

15. Access Token이 기간이 만료되어 401에러가 나면, Refresh Token을 통해  Access Token을 재발급 한다.