Oauth가 나온 배경
Oauth를 사용하기 전에는 인증방식의 표준이 없었기 때문에 한 서비스 내에서 다른 서비스가 제공하는 리소스에 접근하려면 해당 사용자가 쓰는 아이디와 비밀번호를 전달받아서 접근해야됬는데 이때 개인정보가 악용되거나 유출될 위험이 매우 컸다. 따라서 한 서비스가 다른 서비스의 리소스에 안전하게 접근 할 수 있도록 하는 표준 프로토콜의 요구가 커졌고 이는 Ouath가 등장하게된 배경이 되었다.
Oauth란?
사용자의 아이디와 비밀번호를 전달하는게 아니라, 사용자가 소유한 리소스를 다른 어플리케이션에서 대신 작업을 수행할 수 있게 끔 특정 권한을 부여하는 키를 전달하는 방식의 개방향 표준 프로토콜을 말한다.
Oauth의 구성
-
Resource Owner :
자원의 소유자 -
Client :
리소스 서버에 접속해 자원 사용하려는 서비스 -
Resource Server :
데이터를 가지고 있는 서버 -
Authorization server
인증과 관련된 처리를 전담하는 서버
특징
- 인증 표준
- OpenAPI로 개발된 표준 인증 방식
- ID/PW 대신 액세스 토큰으로 인증
- 앱(또는 웹사이트)이 API를 통해 웹서비스에 접근하게 해줌
- 앱 서비스를 제공하는 제3자가 사용자의 ID, 패스워드 대신 Access
- Token을 얻어서 인증이 필요한 데이터에 접근 가능
- 웹서비스 통합인증 구현
- 널리 사용됨: 페이스북, 트위터, MS, 네이버, 다음, 네이트, 구글 등
Oauth의 절차
+--------+ +---------------+
| |--(A)------- Authorization Grant --------->| |
| | | |
| |<-(B)----------- Access Token -------------| |
| | & Refresh Token | |
| | | |
| | +----------+ | |
| |--(C)---- Access Token ---->| | | |
| | | | | |
| |<-(D)- Protected Resource --| Resource | | Authorization |
| Client | | Server | | Server |
| |--(E)---- Access Token ---->| | | |
| | | | | |
| |<-(F)- Invalid Token Error -| | | |
| | +----------+ | |
| | | |
| |--(G)----------- Refresh Token ----------->| |
| | | |
| |<-(H)----------- Access Token -------------| |
+--------+ & Optional Refresh Token +---------------+참고 링크
https://datatracker.ietf.org/doc/html/rfc6749#section-1.5
https://itwiki.kr/w/OAuth
학습 자료
https://dongwooklee96.github.io/post/2021/03/28/rest-api-%EB%B3%B4%EC%95%88-%EB%B0%8F-%EC%9D%B8%EC%A6%9D-%EB%B0%A9%EC%8B%9D/ 'REST API 보안 및 인증방식'
https://www.youtube.com/watch?v=t18YB3xDfXI 'An Illustrated Guide to OAuth and OpenID Connect'
