Oath 2.0 흐름에 대해

단어 정리

Resource Owner :리소스 소유자(=user)를 말합니다. 리소스란 외부 소셜 서비스(API == 개인 정보) 

Authorization Server : Resource Owner를 인증하고, 우리가 개발한 웹 서비스에게 Access Token을 발급해주는 서버
즉 외부 플랫폼 리소스에 접근할 수 있는지 인증을 하는 서버를 의미

Resource Server : 구글,페이스북, 카카오와 같이 보호되는 리소스를 가지는 서버

Client : 유저가 로그인 할려는 웹 사이트. Resource Owner 를 대신해 Authorization Server & Resource Server 에 접근하는 주체입니다.

client_id : client 측에서 개발 당시에 oauth 구현을 위해 리소스 서버의 개발자 페이제에 직접 등록 했을 때 발급 받는 것.

redirect_url: 이 또한 client_id처럼 리소스 서버의 개발자 페이지에 등록 시 발급 받는 것.

eg. http://localhost:3000/auth/naver/callback

 cf) redicrect_url은 통신 시 HTTP 헤더의 Location 에 명시 된 url 로써 응답 메시지로 이것을 받을 시 브라우저는 자동으로 해당 url로 접근하게 됨.( HTTP 상태 코드 3xx와 관련 된 내용  ) 

HTTP/1.1 302 Found
Location: [redirect_uri]?code=[authorization_code]&state=[state]

OAuth 2.0 은 client 가 user 대신에 인증 과정을 거치는 것이다 라고 생각하면 편함.

그러기 위해선 client가 안전한게 맞는지를 검증 하는 과정이 필요. 

흐름

1. 유저가 클라이언트의 로그인 페이지에 접근

2. 유저가 클라이언트의 로그인 페이지에서 구글,카카오,네이버 같은 간편 로그인 버튼을 클릭

3. 클라이언트 측은 유저에게 client_id, redirect_url을 넘겨줌

4. 위의 내용을 받은 유저는 리소스 서버에 client_id와 redirect_url을 넘겨주면서 로그인 요청을 보냄(client가 검증 받은 곳인지 확인하기 위해)

5. 리소스 서버는 그 내용들을 통해 client가 검증 된 곳이라고 판단되면 유저에게 로그인 페이지(구글,카카오,네이버 로그인 페이지)를 제공함

6. 유저가 로그인(구글,카카오,네이버)을 성공하면 리소스 서버는 authorization code(임시 비번)를 유저에게 보냄.

7. 유저는 authorization_code(인가 코드로 칭함)를 client에게 보내줌. 

8. 아까 받았던 client의 redirect_url로 인가 코드를 보냄.

9. client는 유저에게 받은 인가 코드를 리소스 서버에 보내면서 이후 인증에 위해 필요한 Token을 받아옴.

10. 리소스 서버로부터 Token을 받은 client는 유저에게 로그인 완료 됐다고 알려줌.

11. 이후 유저의 정보(이름,사진 등등)에 접근하거나 유저가 인증이 필요한 서비스에 접근할 때마다 client는 해당 Token을 리소스 서버에 보내면서 인증을 받음.

cf) Token에는 access token과 refresh token이 있음

인증을 위해 필요한 실질적인 토큰은 access인데 이것은 만료 기간이 짧음.

access 토큰을 통해 인증을 거치다가 이것이 만료된다면 비교적 만료 기간이 긴 refresh 토큰을 통해 리소스 서버로부터 access 토큰을 새로 발급 받으면서 위의 복잡한 인증 절차들을 새로 받지 않아도 되게끔 함