✏️Oauth란?
Open Authorization
제 3의 앱이 자원의 소유자인 서비스 이용자를 대신하여 서비스를 요청할 수 있도록 자원 접근 권한을 위임하는 방법으로, 인증을 위한 오픈 스탠다드 프로토콜이다.
OAuth 1.0에서 웹 애플리케이션이 아닌 애플리케이션에서는 사용하기 곤란하다는단점을 보완하여 OAuth 2.0가 나타났고, 보안 강화를 위해 Access Token의 Life-time을 지정하여 사용한다.
* 권한 : OAuth는 인증뿐만 아니라 권한도 관리한다. 사용자의 권한에 따라 접근할 수 있는 데이터가 다르도록 설정이 가능하다.
* 프로토콜 : 특정한 프로그램을 지칭하는게 아니라 일종의 규격이다. Facebook, Google, Naver 등은 OAuth라는 규격에 맞춰 인증 및 권한을 대행관리 해준다.
* 외부서비스 : 우리가 만들고 있는 서비스를 이야기한다. 외부 서비스를 위한 서비스인 OAuth는 우리 서비스의 인증 및 권한부여를 관리를 대행해준다.
한 가지 명심해야할 점은, 우리가 배웠던 (사용자 <-> 어플리케이션 서버) 인증 절차였던 세션/쿠키, 토큰 기반 인증 방식을 완전히 대체하는게 아니라는 점이다.
🔑 OAuth 2.0
현재 대다수, 많은 서비스에서 사용하고 있는 Oauth는 2.0 버전이다.
2007년 처음으로 Oauth 1.0의 초안이 발표되었고 그 뒤로는 사람들에게 많이 알려지게 되었다. 그러나 점점 커져가는 네트워크 시장에서 한계가 나타나기 시작했고 2012년 Oauth 2.0을 새롭게 제시하였다.
Oauth 2.0에서 크게 바뀐 점은 다음과 같다.
1. 모바일 어플리케이션에서도 사용이 용이해짐.
2. 반드시 HTTPS를 사용하기에 보안이 강화됨.
3. Access Token 의 만료기간이 생김.
OAuth 2.0의 인증 방식은 크게 4가지이다.
- Authorization Code Grant Type : 권한 부여 코드 승인 타입
클라이언트가 다른 사용자 대신 특정 리소스에 접근을 요청할 때 사용된다. 리스소 접근을 위한 사용자 명과 비밀번호, 권한 서버에 요청해서 받은 권한 코드를 함께 활용하여 리소스에 대한 엑세스 토큰을 받는 방식이다. - Implicit Grant Type : 암시적 승인
권한 부여 코드 승인 타입과 다르게 권한 코드 교환 단계 없이 엑세스 토큰을 즉시 반환받아 이를 인증에 이용하는 방식이다. - Resource Owner Password Credentials Grant Type : 리소스 소유자 암호 자격 증명 타입
클라이언트가 암호를 사용하여 엑세스 토큰에 대한 사용자의 자격 증명을 교환하는 방식이다. - Client Credentials Grant Type : 클라이언트 자격 증명 타입
클라이언트가 컨텍스트 외부에서 액세스 토큰을 얻어 특정 리소스에 접근을 요청할 때 사용하는 방식이다.
각 인증 방식에는 장단점이 존재한다. 가장 많이 쓰이는 Authorization Code Grant 를 살펴보자.
OAuth 2.0 의 동작순서
Resource Owner : User, 즉 일반 사용자.
Client : 우리가 관리하는 어플리케이션 서버
Authorization Server : 권한을 관리하는 서버. Access Token, Refresh Token을 발급, 재발급 해주는 역할을 한다.
Resource Server : OAuth2.0을 관리하는 서버(Google, Facebook, Naver 등) 의 자원을 관리하는 서버. 주의할 점은 우리가 만드는 서버의 자원을 관리하는 곳이 아니다. Oauth 2.0 관리 서버의 자체 API를 의미한다.
1. Resource Owner(사용자)가 Client(우리 서버)에게 인증 요청을 한다.
2. Client는 Authorization Request를 통해 Resource Owner에게 인증할 수단(ex Facebook, Google 로그인 url)을 보낸다.
3. Resource Owner는 해당 Request를 통해 인증을 진행하고 인증을 완료했다는 신호로 Authorization Grant(code)를 url에 실어 Client에게 보낸다.
4. Client는 해당 권한증서(Authorization Grant)를 Authorization Server에 보낸다.
5. Authorization Server는 권한증서를 확인 후, 유저가 맞다면 Client에게 Access Token, Refresh Token, 그리고 유저의 프로필 정보(id 포함) 등을 발급해준다.
6. Client는 해당 Access Token을 DB에 저장하거나 Resource Owner에게 넘긴다.
7. Resource Owner(사용자)가 Resource Server에 자원이 필요하면, Client는 Access Token을 담아 Resource Server에 요청한다.
8. Resource Server는 Access Token이 유효한지 확인 후, Client에게 자원을 보낸다.
9. 만일 Access Token이 만료됐거나 위조되었다면, Client는 Authorization Server에 Refresh Token을 보내 Access Token을 재발급받는다.
10. 그 후 다시 Resource Server에 자원을 요청한다.
11. 만일 Refresh token도 만료되었을 경우, Resource Owner는 새로운 Authorization Grant를 Client에게 넘겨야한다. (이는 다시 사용자가 다시 로그인 하라는 것)
🔍참고 : Access Token, Refresh Token을 이용한 인증 방식은 한 서버에서 모두 관리하는 반면, 여기 OAuth에서는 Authorization Server에서 인증+권한 관리를 하고 Resource Server에서는 자원에 대한 관리만 한다.
Oauth facebook login example
1. 사용자(Resource Owner)가 서버에게 로그인을 요청한다.
2. 서버는 사용자에게 특정 쿼리들을 붙인 페이스북 로그인 URL을 사용자에게 보낸다.
3. 사용자는 해당 URL로 접근하여 로그인을 진행한 후 권한증서(code)를 담아 서버에게 보낸다
4. 서버는 해당 권한 증서를 Facebook의 Authorization Server로 요청한다.
5. 서버는 권한 증서를 확인 후, Access Token, Refresh Token, 유저의 정보(고유 id 포함) 등을 리턴한다.
** 여기서 프로필 이미지나 이메일 주소, 이름 등을 얻을 수도 있는데 이는 초기에 관리자가 권한 설정을 어디까지 하느냐에 따라 다르다. 페이스북 이름에 대해서만 접근할 수 있는 권한을 설정하면 이름 값만 Authorization Server에서 돌려줄 것 이다.
6. 받은 고유 id를 key값으로 해서 DB에 유저가 있다면 로그인, 없다면 회원가입을 진행한다.
7. 로그인이 완료되었다면 세션/쿠키 , 토큰기반 인증 방식을 통해 사용자의 인증을 처리한다.
** 우리가 만들 서버에서 OAuth를 이용하기 위해서는 사전에 OAuth에 등록하는 과정이 필요하다. 등록 후 APP_ID와 CLIENT_ID 등을 보내야 OAuth 에서는 어느 서비스인지를 알 수 있다.
** 페이스북 로그인을 인증을 이용하는 경우, 대부분은 Resource Server(페이스북 자체 API)를 사용하지 않는다. 따라서 Access Token, Refresh Token은 실제로 쓰이지 않습니다. 우리의 서버에서 access token을 검증할 수도 없을 뿐더러 인증의 수단으로 활용하기엔 부족한 점이 많다. 따라서 보통 7번 절차처럼 Authorization Server로 부터 얻는 고유 id값을 활용해서 DB에 회원관리를 진행한다.
참고 : https://tansfil.tistory.com/60
