OAuth 2.0

OAuth

Open Authorization

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

-> OAuth 2.0은 1.0에서 알려진 보안 문제 등이 개선된 버전

 

우리의 서비스가 우리 서비스를 이용하는 유저의 타사 플랫폼 정보에 접근하기 위해서 타사 플랫폼으로부터 권한을 위임받는 것

어플리케이션 등록

OAuth 2.0 서비스를 이용하기 전에 선행되어야 하는 작업

-> Client를 Resource Server에 등록

 

이때 Redirect URI를 등록해야 함

동작 원리

1. Resource Owner가 우리가 설계한 서비스의 "~로 로그인하기" 등의 버튼을 통해 로그인 요청을 보냄

2. Client는 OAuth 프로세스 시작을 위해 Resource Owner의 브라우저를 Authorization Server로 보냄

3 ~ 4. Resource Owner는 제공된 로그인 페이지에서 ID, PW를 통해 인증

5 ~ 6. 사용자가 인증에 성공하면 Authorization server는 Resource Owner에게 Authorization Code를 제공하고 해당 코드를 Client에게 전달

7. Authorization Code를 통해 Client가 Authorization Server에서 Access Token을 발급받은 뒤 Resource Server에 Access Token을 이용해서 요청                                                                                                                

Authorization Code를 이용하는 이유?

곧바로  Client에게 Access Token을 발급하면 안될까?

-> 만약 Authorization Code를 발급하는 과정을 생략하면 Authorization Server가 Access Token을 Client에 전달하기 위해 Redirect URI를 통해 URL 자체에 데이터를 실어 전달해야 함

브라우저를 통해 데이터가 곧바로 노출

Access Token은 절대 외부에 노출되어서는 안돼!

 

---

Resource Owner 리소스 소유자, 웹 서비스를 이용하면서 타플랫폼에서 리소스를 소유하고 있는 사용자

Authorization Server 권한을 부여 해주는 서버

사용자는 해당 서버에 ID, PW를 넘겨 Authorization Code를 발급받고 Client는 이 서버로 Authrization Code를 넘겨 Token을 발급받음

Resource Server 사용자의 개인정보를 가지고 있는 타플랫폼 서버

Client는 Token을 해당 서버로 넘겨 개인정보를 응답 받음

Client 자사 또는 개인이 만든 서버

Authorization Code Access Token을 제공받기 위해 사용하는 임시 코드, 수명이 매우 짧음

Redirect URI 사용자가 OAuth 2.0 서비스에서 인증을 마치고 사용자를 redirection 시킬 위치

기본적으로 보안을 위해 https만 허용되지만 루프백(localhost)는 예외적으로 http 허용