참고 사이트 : https://d2.naver.com/helloworld/24942
OAuth
OAuth는 인증을 위한 오픈 스탠더드 프로토콜로, 사용자가 Facebook이나 트위터 같은 인터넷 서비스의 기능을 다른 애플리케이션 등에서도 사용할 수 있게 하는 것이다.
OAuth 1.0은 2007년에 나온 비공식 논의체에 의해 최초로 만들어진 것이고, 2010년 IETF OAuth 워킹 그룹에 의해 이 프로토콜이 표준 프로토콜로 발표되었다.
현재 나와 있는 OAuth 2.0은 OAuth 1.0과 호환되지 않지만, 인증 절차가 간략하다는 장점이 있다.
OAuth와 로그인
OAuth의 Auth는 Authentication(인증) 뿐만 아니라 Authorization(허가) 또한 포함하고 있는 것이다.
서비스에 직접 로그인한 사용자와 OAuth를 이용해 권한을 인증받은 사용자는 할 수 있는 일이 다르다.
OAuth 발급 과정
- 나방문씨(외부 손님)가 안내 데스크에서 업무적인 목적으로 김목적씨(회사 사원)를 만나러 왔다고 말한다.
- 안내 데스크에서는 김목적씨에게 나방문씨가 방문했다고 연락한다.
- 김목적씨가 안내 데스크로 찾아와 나방문씨의 신원을 확인해 준다.
- 김목적씨는 업무 목적과 인적 사항을 안내 데스크에서 기록한다.
- 안내 데스크에서 나방문 씨에게 방문증을 발급해 준다.
- 김목적씨와 나방문씨는 정해진 장소로 이동해 업무를 진행한다.
즉,
- Request Token 요청과 발급
- 사용자 인증 페이지 호출
- 사용자 로그인 완료 -> 아마 인증 완료
- 사용자의 권한 요청 및 수락 -> 허가 완료
- Access Token 발급
- Access Token 이용해 서비스 정보 요청
각각 해당 일을 수행한다.
OpenID와 OAuth
OpenID도 인증을 위한 표준 프로토콜이고, HTTP를 사용한다는 점에서 OAuth와 같다. 그러나 OpenID와 OAuth의 목적은 다르다.
OpenID의 주요 목적은 인증(Authentication)이지만, OAuth의 주요 목적은 허가(Authorization)이다.
즉, OpenID를 사용한다는 것은 로그인하는 행동과 같다. OpenID는 OpenID Provider에서 사용자와 인증 과정을 처리한다. OpenID를 사용하는 여러 서비스(Relying Party)는 OpenID Provider에게 인증을 위임하는 것이다.
OAuth 1.0 은 패스하고….
OAuth 2.0
OAuth 1.0은 웹 애플리케이션이 아닌 애플리케이션에서는 사용하기 곤란하다는 단점이 있다. 또한 절차가 복잡하여 OAuth 구현 라이브러리를 제작하기 어려운 등의 복잡한 절차 때문에 Service Provider에게도 연산 부담이 발생한다.
OAuth 2.0은 이러한 단점을 개선한 것이다. 비록 OAuth 1.0과 호환성이 없지만, 여러 인터넷 서비스 기업에서 OAuth 2.0을 사용하고 있다.
OAuth 2.0 특징
- 웹 애플리케이션이 아닌 애플리케이션 지원 강화
- 암호화가 필요없다. HTTPS를 사용하고 HMAC을 사용하지 않는다.
- Signature 단순화 정렬과 URL 인코딩이 필요 없다.
- Access Token 갱신 : OAuth 2.0에서는 보안 강화를 위해 Access Token의 Life-time을 지정할 수 있도록 하였다.