OAuth 2.0

1. OAuth란?

 

- OAuth는 Open Authorization, Open Authentication 뜻으로 오픈 스탠다드 프로토콜을 말하는

 

데, OAuth 2.0은 다양한 플랫폼 환경에서 권한 부여를 위한 산업 표준 프로토콜이다.

 

- 애플리케이션(페이스북,구글,트위터등- Service Provider)의 유저의 비밀번호를 나의 서비스에 

 

제공 없이 사용자 인증,인가를 할 수 있는 기술 이다. 

 

- 또는 제 3의 앱이 자원의 소유자(서비스 이용자)를 대신하여 서비스를 요청할 수 있도록 자원 접

 

근 권한을 위임하는 방법이다.

 

 

2. OAuth라는 기술과 관련 3명의 참여자

 

- Mine  = 나의 서비스

 

- User  = 사용자(나의 서비스를 사용하는자 )

 

- Their (나의 서비스가 연동하려고 하는 다른 서비스) = 구글, 페이스북, 트위터등

 

 

 

3. OAuth라는 기술이 나오게 된 배경

 

나의 서비스가 사용자가 가입한 구글과 같은 서비스의 API에 사용자 대신 접근하여 CRUD

 

를 하고싶다면 사용자로부터 구글의 서비스에 접근할수 있도록 허가를 받아야 한다. 즉 권한을 위

 

임 받는것이다.

 

가장 쉬운 방법은 사용자로부터 아이디와 비밀번호를 받아서 기억하고있다가 접속할때 아이디와

 

비밀번호를 이용하는것이다. 하지만 사용자의 중요한 개인정보를 타 서비스에 맡기는것도 위험하

 

고 서비스를 하는 기업입장에서도 사용자의 정보를 가지고 있는것은 위험성이 있다.

 

그래서 사용자의 아이디, 패스워드 없이도 권한을 위임 받을 수 있는 방법이 필요하다.

 

그래서 이러한 문제점에서 OAuth라는 기술이 고안 되었다. OAuth기술을 사용해

 

훨씬 더 안전한 방법으로 타 서비스와, 나의 서비스가 상호작용 할수 있는것이다. 

 

 

4. OAuth기술의 핵심 요약

 

OAuth 를 통해서 나의 서비스가, 타 서비스로부터 accessToken을 얻어낼수있다는게 가장 핵심이다.

 

 

 

4-1) 유저의 요청에 의해서, 타 서비스가 accessToken을 나의 서비스에 발급해준다

 

accessToken은 타 서비스의 비밀번호와 아이디가 아닌 장점을 가지면서도, 그 역할을 대신해주는것으로 볼 수 있다.

 

accessToken을 가지고 있다면, 타 서비스가 가지고 있는 모든 기능이 아니라 나의 서비스가 필요로 하는 기능만 부분적으로 허용하는 것이다.

 

4-2) 즉 accessToken을 통해서, 타 서비스에 접근해서 데이터를 CRUD할수 있는것이다.  

 

4-3) OAuth 기술을 사용하면 처음부터 회원들의 아이디와 비밀번호를 보관하지 않고도 회원들을 식별할수 있다.

 

4-4) OAuth를 이용해서 다른 서비스에 접근할 수 있는 권한을 획득할 수 있고, 반대로 다른 서비스에게 권한을 부여할수도 있다.

 

 

 

5. OAuth라는 기술과 관련한 3자 관계 재정의

 

 

 

- Resource server : 나의 서비스가 제어하고자 하는 자원, 데이터를 가지고 있는 서버라는뜻

(이름, 나이 등 아이디 관련 정보를 제공하는 서버, 구글,페이스북등)

 

- Authorization Server :  인증과 관련된 처리를 전담하는 서버이고

(로그인을 통해 인증 후 권한을 부여하는 서버. 구글, 페이스북 등)

 

- Resource Owner : 자원의 소유자를 뜻 한다.

 

- Client : Resource server에 접속해서 정보를 가져가는자

 

6. Register : 클라이언트 등록

 

Client가 Resource server를 이용하기 위해서는 Resource server에 승인을 사전에 받아놔야한다.

 

 

 

핵심적인것들 3가지

 

 

Client ID: 내가 만들고있는 애플리케이션의 식별자 아이디이다.

 

Client Secret: 아이디의 비밀번호

 

Authorized redirect URI : 리소스 서버가 권한을 부여하는 과정에서 Authorized 코드를 client에게 

 

최종적으로 전달해줄건데, 그것을 전달해 줄 주소이다. 리소스 서버는 이 주소 말고, 다른주소로 요

 

청하면 무시한다.

 

등록하게 되면 클라이언트와 리소스서버는 둘다 3가지를 알고있게 된다.

 

 

7. Resource Owner의 승인

 

OAuth의 첫번째 절차는 Resource Owner가 Resource Server에게 Client의 접근을 승인한다는 것을 알려줘야 한다.

 

 

 

 

 

리소스 owner가 저 주소로 접속을 해서 client의 접근을 승인한다는 의미로

 

로그인을 하게되면 리소스 서버는같은 client id, redirect url ,scope에 대한 값이 일치하는지 확인

 

후 서버에 리소스 owner의 아이디(user id), scope를 저장하게된다.

 

이로써 리소스 owner의 허락을 받게된거다.

 

 

8. Resource Serve의 승인

 

Resource Server는 Client가 등록된 Client가 맞는지 확인하기 위해서 Resource Owner을 통해서 

 

Client에게 Authorization code를 전달한다. 이때 사용하는 임시 비밀번호가 authorization code

 

이다. authorization code를 리소스서버는 리로스 오너에게 전송

 

 

 

 

응답할때 헤더라는값에 location을 줘서 저 주소로 이동하도록 명령

 

client는 authorization code값을 얻는다.

 

이상태가 accessToken을 발급하기 전 상태이다.

 

그리고 클라이언트는 리로스오너를 통하지않고 리소스 서버에 직접 접속한다.

 

 

 

이 값들을 Resource Server로 전송한다. 그리고 리소스 서버는 보내진 정보가 일치하는지 확인하

 

고 Client의 신원을 증명한다.

 

9. OAuth 2.0의 총 6 가지 인증 방식(grant type)

 

oauth의 핵심은 클라이언트 입장에서 제3자인 리소스 서버(구글)를 통해서 리소스 오너의 신원을 인증할수 있다는것이다.

 

인증 Grant Type이란 Client가 액세스토큰을 발급받기 위한 플로우라고 보면 된다

1) Authorization Code Grant (인가 코드 그랜트 타입)

 

OAuth2.0 Grant Type에서 가장 잘 알려진 인가 코드 그랜트 타입은 중요한 보안 이점을 제

 

공하는 방법이다. 일반적인 웹사이트에서 소셜로그인과 같은 인증을 받을 때 가장 많이 쓰

 

는 방식으로 기본적으로 지원하고 있는 방식이다. 클라이언트는 토큰을 발급 받기 전에 인증

 

코드라는 것을 사전에 리소스 소유자에 의해서 받게 되고 그 인증코드(권한 부여코드)를 가

 

지고 인증서버에 요청을 보내야 토큰을 발급받을 수 있다. 

 

2) Implicit Grant (암시적 그랜트 타입)

 

암시적 그랜트 타입은 서버가 없는 단순 웹 브라우저에서 직접 실행되는 자바스크립트 웹 애

 

플리케이션 클라이언트에게 적당한 권한 부여 방법이다. 별다른 인증방법없이 클라이언트

 

가 요청을 보내면 리소스 소유자의 Authentication(+사용자 동의 과정) 과정만 거치고 바로 

 

토큰을 발급해준다. 이 그랜트 타입은 클라이언트가 토큰을 안전하게 보관할 방법이 없기때

 

문에 리프레시 토큰을 발급해주지 않는다.

 

3) Resource Owner Password Credentials Grant 

 

Client에 아이디/패스워드를 받아 아이디/패스워드로 직접 access token을 받아오는 방식이

 

다. Client가 신용이 없을 때에는 사용하기에 위험하다는 단점이 있다. 클라이언트가 확실한 

 

신용이 보장될 때 사용할 수 있는 방식이다.

 

4) Client Credentials Grant 

5) Device Code Grant 

6) Refresh Token Grant

 

10. access token의 값을 발급

 

 

 

리소스 서버는 access token을 발급해준다. 클라이언트에게 응답한다.

 

그러면 클라이언트는 access token을 저장후, access token을 가주고 리소스 서버에 접근하면 

 

리소스 서버는 access token을 보고서 userid 1번에 해당하는 사용자의 기능 b,c에 대해 허용해주

 

는것이다. 즉 crud하는것이다.

 

 

11. Refresh token

 

Access token은 수명이 있다.

 

Access token의 수명이 다했을 때 api로 접근하면 더이상 데이터를 주지 않는다.

 

새로운 access token을 발급 받는 방법이 refresh token이다.

 

 

A : 권한을 획득한다. access token을 발급받는것

 

B: access token과 함께 Refresh token도 발급하고 저장해둠

 

C,D: API를 호출할때 access token을 제출해 보호된 자원들을 가져옴

 

E: 계속해서 자원을 가져오다가

 

F: access token의 수명이 끝나 유효하지 않게 된다.

 

G: 인증 서버에게 Refresh token을 전달하면서 

 

H: 다시 access token을 발급 받는다.

 

 

12. 전체 인증 과정 요약도

 

 

 

참고자료

https://www.opentutorials.org/course/3405

https://meetup.toast.com/posts/105

https://stackoverflow.com/questions/32964774/oauth-or-jwt-which-one-to-use-and-why